Payment process

The payment process in Optimizely Configured Commerce has a few variations, depending on whether you enabled Saved Credit Cards on your website. Your ERP may also require 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 below. For more information about TokenEx, read the iFramed Credit Card Processing for Cloud article.

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 Configured Commerce.

   TokenEx is Optimizely's partner for PCI compliance in our Cloud environment, which also provides functionality that enables saved cards on the storefront. While Configured Commerce never stores actual card data, TokenEx removes additional risk by never technically handling sensitive card data.

   All Cloud implementations have TokenEx enabled.

3. TokenEx returns Card Token to Configured Commerce.

   Configured Commerce 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. (Optional) Configured Commerce saves credit card data.

   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). See Saved credit cards to learn more.

5. TokenEx receives the payment authorization request from Configured Commerce.

   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 Configured Commerce.

7. (Optional) Configured Commerce requests the card token from the Payment Gateway.

   If payment gateway vaults are available and enabled for your payment gateway, Configured Commerce 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.

   Configured Commerce 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 Configured Commerce 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.