Probably put this in the wmf-civicrm module
This is supposed to resolve a single transaction by either capturing it (moving it from status 600 to 800), canceling it, or discarding it (already failed).
- called with an array of data in the format that is stored in the pending table
- implements the basic flow from DonationInterface's IngenicoGateway::rectifyOrphan without relying on DonationInterface
- including canceling pending donations where a contribution already exists with the same contribution tracking ID
- get hosted checkout status based on gateway_session_id
- if that status has 'tokens' field and pending message's is_recurring is true, add the token to any output message as recurring_payment_token
- if status code is 600, check fraud score (see T291230) and decide whether to capture payment
- send message to antifraud queue with results of fraud score
- if fraud score is > REJECT threshold, cancel payment
- if fraud score is fine, call approvePayment and send a message to the donations queue
- this version only has to work for Ingenico, so for now we can deal with the non-normalized return value from SmashPig's Ingenico\HostedCheckoutProvider::getHostedCheckoutStatus
- at this point in the year we should probably not refactor SmashPig in a way that affects payments-wiki's Ingenico flow
- Where possible, still try to write in a gateway-agnostic way. Add TODOs for places that are Ingenico-specific.
- next year when we rewrite the PayPal integration would be the time to refactor getHostedCheckoutStatus to return a new, normalized PaymentProviderResponse subclass
You can also refer to the SmashPig Civi extension for examples of capturing a payment directly from CiviCRM and sending a message to the donations queue.