Talk:Fundraising tech/Chat/Ingenico Connect

Jump to navigation Jump to search

About this board

How to order the work to get results before moving the whole gateway into SmashPig

2
EEggleston (WMF) (talkcontribs)

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.

EEggleston (WMF) (talkcontribs)

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

Reply to "How to order the work to get results before moving the whole gateway into SmashPig"

How should we handle the hostedCheckoutId vs the paymentId

2
EEggleston (WMF) (talkcontribs)

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.

EEggleston (WMF) (talkcontribs)

hHostedCheckoutId is only valid for 2 hours, so we shouldn't need to put it anywhere except the pending DB.

Reply to "How should we handle the hostedCheckoutId vs the paymentId"
EEggleston (WMF) (talkcontribs)
CDentinger (WMF) (talkcontribs)

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

EEggleston (WMF) (talkcontribs)

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!

CDentinger (WMF) (talkcontribs)

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.

Reply to "Should we use the SDK?"

How much of the integration should we push down into SmashPig?

3
EEggleston (WMF) (talkcontribs)

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?

EEggleston (WMF) (talkcontribs)

We don't have our cross-gateway abstractions nailed down in SmashPig. How are the PaymentResult, PaymentTransactionResponse, etc things working out for us?

EEggleston (WMF) (talkcontribs)
Reply to "How much of the integration should we push down into SmashPig?"

Should we create a new gateway?

2
EEggleston (WMF) (talkcontribs)

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

CDentinger (WMF) (talkcontribs)

Definitely seems worth the new gateway to me, many advantages to starting fresh.

Reply to "Should we create a new gateway?"
There are no older topics