Payment process

  • Updated

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 instead of an authorization token to process a transaction, which requires you to enable and use your payment gateway's vault.

Review the following flows to identify which applies to your configuration, then read more details about each step. For information about Spreedly, see Payment gateway development expectations.

  1. The customer enters checkout and pays with a credit card.

    For any customer card data to enter the system, they must use a payment method that supports credit cards.

  2. The customer enters data into the Spreedly iFrame.

    When customers select a credit card payment method, they can enter their cardholder data through the Spreedly iFrame. Spreedly collects the Primary Account Number (PAN) and CVV, and Configured Commerce captures the other form fields, such as Expiration Date and Cardholder Name.

    Spreedly is Optimizely's partner for PCI compliance and provides functionality to save cards on the storefront. While Configured Commerce never stores actual card data, Spreedly removes additional risk by never technically handling sensitive card data.

  3. Spreedly returns Card Token to Configured Commerce.

    Configured Commerce receives the Spreedly 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, Configured Commerce saves the Spreedly card token in the UserPaymentProfile table. The customer who saved the card can retrieve it for use later and only needs to enter their CVV (step 2). See Manage saved credit cards.

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

    Spreedly functions as a transparent gateway. The request to the payment gateway is sent to Spreedly with tags to insert appropriate cardholder data from the iFrame (PAN, CVV).

  6. Spreedly sends the payment authorization request to the payment gateway.

    Spreedly 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 to the payment gateway through Spreedly 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. Spreedly tokens are not sent to the ERP and are not used outside of Configured Commerce. If your website does not use a standard ERP connector, you must implement these fields in the Order Submit job you created.

  9. ERP processes the information.

    When the ERP receives payment information, the funds are generally captured when an order enters a particular status, which differs by ERP.