# Transaction Flow

# Existing Flow

User sees and goes through the standard e-commerce checkout flow
On payment page we have full access to read credit card information
If we have sponsorship or recurring gift transaction then:
- Scripts read credit card information from the payment page
- Scripts stop the e-commerce transaction submission
- Scripts submit the transaction to the donation API, using the credit card information read from the payment page
- After the API submissions, the scripts trigger normal e-commerce transaction flow
UX: The user is not aware at any point that they may be submitting 1-3 transactions, they only clue is multiple autoresponders

On payment page we do not have ability to read credit card information, all the interaction happens in the iframe inside an iframe, which limits our ability to submit the same payment information to e-commerce and donation API
If we have sponsorship or recurring gift transaction then per new flow we'll need to do the following:
- Scripts stop the e-commerce transaction submission
- Scripts submit the transaction to the donation API to validate the input
- Scripts display the new payment modal, user enters their payment information for sponsorship/recurring gift transaction
- After the API submissions, the scripts trigger normal e-commerce transaction flow
- The e-commerce transaction will also display another payment modal, user enters their payment information for gift catalog transaction
UX: The user will have to enter their payment information into a modal for each transaction separatey, which will likely create a confusion and possibly mistrust

The checkout or modal that renders payment scripts are rendered in an iframe, making content inacessisble to scripts
The payment fields themselves are rendered in another iframe within the existing iframe, making payment information inaccessible to scripts.

transaction flow