Payments
Describes payments in Optimizely Configured Commerce.
The life of a payment in Optimizely Configured Commerce has a few variations, depending on whether you enabled Saved Credit Cards on your website and/or your ERP requires a payment card token to process a transaction as opposed to an authorization token, which requires you to enable and use your payment gateway's vault.
Review the following flows to identify which one applies to your configuration, then read more details about each step in the table. For more information about TokenEx, read the iFramed Credit Card Processing for SDK article.
| Step | Step Name | Description |
|---|---|---|
| 1 | Customer enters checkout and pays with a credit card | For any customer card data to enter the system, first they must engage with a payment method that supports credit cards. |
| 2 | Customer enters data into TokenEx iFrame | Once a customer selects a credit card payment method, the TokenEx iFrame is rendered and the customer can enter their Cardholder Data, which is collected by TokenEx. TokenEx collects the Primary Account Number (PAN) and CVV, whereas the other fields (Expiration date, Cardholder Name) are form fields and captured by <>. TokenEx is Optimizely's partner for PCI compliance in our Cloud environment, which also provides functionality that enables saved cards on the storefront. While <> never stores actual card data, TokenEx removes additional risk by never technically handling sensitive card data. All Cloud implementations have TokenEx enabled. (SDK/Self-Managed customers are responsible for their own PCI-DSS compliance and can choose to open their own TokenEx account.) |
| 3 | TokenEx returns Card Token to <> | <> receives the TokenEx card token and stores it in the CreditCardTransactions table as Token1. The system also stores this card in the UserPaymentProfile table for Saved Credit Cards. |
| 4 | <> saves credit card data?(OPTIONAL) | If you enabled Saved Credit Cards on your website and the customer saves their card for future use, the TokenEx card token is also saved in the UserPaymentProfile table. The customer who saved the card will be able to retrieve it for use later and only needs to enter their CVV (step 2). |
| 5 | TokenEx receives the payment authorization request from <> | TokenEx functions as a transparent gateway ? the request to the payment gateway is sent to TokenEx with tags for TokenEx to insert appropriate Cardholder Data from the iFrame (PAN, CVV). |
| 6 | TokenEx sends the payment authorization request to the payment gateway | TokenEx submits the request with actual cardholder data to the payment gateway. The payment gateway processes the request and sends a response to <>. |
| 7 | <> requests the card token from the Payment Gateway (OPTIONAL) | If payment gateway vaults are available and enabled for your payment gateway, <> makes an additional request, through TokenEx, to the payment gateway to retrieve its card token. This value is stored in the CreditCardTransactions table as Token2. Many ERPs use this token to create follow-up charges on a particular transaction for shipping or additional products, or for customers who may have a long tail between order and shipment and are not able to capture funds during the life of the original authorization request. |
| 8 | Order Submit job/API call sends information to ERP | <> submits the authorization and/or payment gateway token, if applicable, for standard ERP connectors. TokenEx tokens are not sent to the ERP and are not used outside of the <> system. If your website does not use a standard ERP connector, you still need to implement these fields in the Order Submit job/call you created. |
| 9 | ERP processes the information | Once the payment information has made its way into the ERP, the funds are generally captured once an order enters a particular status, which? differs by ERP. |
Updated 10 months ago