Fundraising tech/Adyen

Overview
Adyen is our backup credit card processor. Our integration with them uses both their hosted form and the 'classic integration' with their API. It looks like our Ingenico integration from a donor's perspective. The donor fills out the name / address / email and clicks on a card type to open an iframe (or full redirect) with inputs for their credit card details.

Hosted Payment Pages
This is their Hosted Payments Page (HPP) method of integration, which keeps all credit card info off our server. We send the donor's name, address, email address, and language along with amount, currency, fraud score, and contribution tracking id, all signed with a shared secret (request documentation). We add a message with donor info, fraud score, and order ID to the pending table before presenting the Adyen frame to the donor. When the donor returns to our page, we get an indication if the charge has been authorized. We do not immediately capture the funds.

'''To configure skins for their hosted payment pages, you have to do all the work on their TEST settings page and publish to production. The 'skins' section is completely missing from their live settings page.'''

Data Flow
After the donor enters their details on Adyen's site, the following sequence begins.


 * Adyen authorizes the payment with the network (i.e. Visa) and sends an Authorization IPN message to SmashPig
 * If authorization was refused, SmashPig deletes the donor data from the pending table
 * If successful, SmashPig adds a ProcessCaptureRequestJob to the jobs-adyen queue, including the CVC result and AVS result codes from the Authorization message
 * Process-control runs Adyen job runner
 * ProcessCaptureRequest job assigns fraud scores to the CVC result and AVS result and adds them to the fraud score from the pending table message
 * If the result is under the 'review' threshold, the job submits a capture request to Adyen
 * If the result is between the 'review' and 'reject' thresholds, the job does nothing. The payment stays at 'Authorized' in the merchant console, and the donor data remains in the pending table.
 * If the result is above the 'reject' threshold, the job submits a cancel request to Adyen and deletes the donor data from the pending table
 * Cancel and capture requests are submitted via the SOAP API, using logic contained in WSDL-generated Payment.php
 * Adyen sends Capture IPN message to SmashPig (either because we captured it automatically, or because someone manually requested capture in the merchant console)
 * SmashPig adds a RecordCaptureJob to the jobs-adyen queue, including Adyen's internal transaction ID
 * Process-control runs Adyen job runner
 * RecordCaptureJob removes the donor data message from the pending table, adds gateway_txn_id, and sends the message to the donations queue
 * Process-control runs donations queue consumer, creating donor and contribution records in Civi.

Apple Pay Overview (TBC):

 * Implemented using https://docs.adyen.com/payment-methods/apple-pay/web-component
 * Using "own certificate" approach

Apple Pay Testing Links (TBC):

 * Apple Pay Developer Account login here
 * Apple Pay test cards here
 * Fundraising-tech Apple Pay Sandbox tester accounts here
 * Fundraising-tech Apple Pay Test Server List here

Using Apple Pay test servers with fundraising-dev docker stack (TBC)

 * WIP Patches
 * DonationInterface patch
 * SmashPig patch
 * fundraising-dev patch
 * Run setup.sh and apply Apple Pay payments-wiki overrides