We eventually want to move all of the DonationInterface business logic into SmashPig, but we need to be able to use the new API before that's done.
Let's focus on building the SmashPig functionality from the bottom up, replacing just the curl_transaction function if possible.
The existing GlobalCollect adapter has some logic that we can re-use for a first draft.
- all of the configuration except var_map
- data staging should be the same
- processResponse deals with error codes which are identical across gateways
- The confirm_creditcard function is huge and gross, but it's got some subtleties that might be a pain to recreate.
I'd like to start by subclassing that and replacing only the functions that deal with the curl request and parsing XML.
curl_transaction will ignore the argument and instead use objects from SmashPig to call the new API
Early attempt at creating the Ingenico shell here: https://gerrit.wikimedia.org/r/364143
paymentId makes sense to store as the gateway_txn_id long term, as it's the value we'll need to use for refunds. The hostedCheckoutId is what we use to get the payment status on the donor's return or during orphan rectifying.
hHostedCheckoutId is only valid for 2 hours, so we shouldn't need to put it anywhere except the pending DB.
See this spike: https://phabricator.wikimedia.org/T152649
And the code: https://github.com/Ingenico-ePayments/connect-sdk-php
SDK docs: https://developer.globalcollect.com/documentation/sdk/server/php/
Do we like the looks of their code?
Drawbacks of using the SDK:
Code seems like a classic PHP inheritance stew, but readable enough and it's already there so I definitely think we should use it. One problem I see is that it requires PHP5.4 and we are still dependent on 5.3
One giant positive from using the SDK: we get to delete all the crazy XML functions from the base gateway adapter class. Actually, we'll get to do that even if we make our own REST requests. So yay either way!
After further investigation, the Ingenico SDK seems good enough to handle the API layer, and it's supported, which is great. This leaves us with the responsibilities of the forms (DonationInterface), and configuration, fraud checking, DB/queue interaction, and certainly other things I'm not thinking of, which are all in SmashPig right now. A more composition-based approach might look like pulling fraud checking, and whatever other things, into standalone modules so that SmashPig's responsibility could be as close to just implementing them and providing configuration as possible. For the time being SmashPig could contain shims for anything that became its own repo.
One of our long term goals is to migrate non-UI functionality into SmashPig. We could do that with Ingenico. Would it basically be a wrapper around their SDK that applies our settings and translates their error codes?
We don't have our cross-gateway abstractions nailed down in SmashPig. How are the PaymentResult, PaymentTransactionResponse, etc things working out for us?
Here is Wikimedia Deutschland's recently-refactored fundraising frontend: https://github.com/wmde/FundraisingFrontend Here's the story of the refactor: https://www.entropywins.wtf/blog/2016/11/24/rewriting-the-wikimedia-deutschland-funrdraising/
It's standalone PHP7 application that inserts donations and memberships directly into a database, so nothing we can directly use.
Looking at it to see if there are any cross-gateway abstractions we can use. Not seeing much at first glance!
Pro:
match company's new name distinguish new from old transactions, as they'll use different refund methods, different console lookups
Con:
loss of continuity in reports, lots of things to rename in code
Definitely seems worth the new gateway to me, many advantages to starting fresh.
