Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Introduction

This article serves as an integration guide for developers/product managers of any business who wish to use Sodexo and Zeta money as a payment instrument on their user payment flows.

Note

Payment exceptions occur when an API operation fails to process a request payload. See Error Codes to know more about exception response codes.

Terminology Used

EntityDescription

User

The customer who purchases products on the e-commerce application.

Merchant

The Sodexo merchant whose products are being purchased.

Requester

A merchant aggregator who sells goods/services of Sodexo acquired merchants and requests transactions on merchant’s behalf.

Integration Methods

The Sodexo E-Com integration involves the checkout flow and save card flow. The details of each flow is described below.

Checkout Flow

Below are the payment flows which depict the non-compliancy and compliancy with the PCI DSS Standards.

Non-PCI DSS Flow

The following payment flow is for merchants who are not compliant with PCI DSS standards:

  1. User adds items to the cart on the e-commerce application and goes to the checkout page.

  2. User clicks on PayWithSodexo option for the payment.

  3. The requester’s/merchant’s web site shows below payment options to the user:

    1. Saved Sodexo card

    2. Checkout with a new card

      Note

      The flow remains the same for both options except for the fact that user needs to enter the card details if he/she chooses to go with the "checkout with a new card" option. 

      Let’s assume user chooses to go with "checkout with a new card" option.

  4. The requester’s/merchant's server makes a "Create a Transaction" call to Zeta and in return gets redirectUserTo URL (a Zeta domain secured page where user completes the authorization of the transaction) including other details mentioned in API response.
    The authorization step is completed in Zeta’s secured domain.

    1. In case of Saved Card: the "Create a Transaction" call needs an extra parameter of sourceId to be provided. This sourceId is an identifier available with the requester.

    2. In case of a New Card: the "Create a Transaction" call will have sourceId as null

  5. The requester/merchant redirects the user to "redirectUserTo" page to complete the authorization.

  6. The user enters the card number, CVV and expiry date. User also chooses whether to allow saving of the card for the convenience of future transactions. See the mobile/web flow below:

  7. User gets redirected to Access Control Server (ACS ) page in Zeta domain where he/she is prompted to enter the card/super card PIN based on the issuer of the card. User enters the PIN and submits it. This step completes the transaction authorization. See the mobile/web flow below:

  8. Based on authorization success or failure the user gets redirected to requester’s/merchant’s successUrl or failureUrl. See the mobile/web flow of success and failure scenarios below:

  9. In above redirection, the requester gets the "q=<xxxxx>" as a query parameter. The requester/merchant calls "Get Transaction Details" API to validate the transaction state and transaction amount for the transaction created with requestId = xxxxx. 

    Note

    If the user has chosen to "save the card" in step 6 "Get Transaction Details" response will also return the sourceId that can be saved and used in future transactions.


  10. After successful validation, the merchant/requester should consider the transaction is completed.

PCI DSS Flow

The following flow is for the merchants who are compliant with PCI DSS standards:

  1. User adds items to the cart on the e-commerce application and goes to the checkout page.
  2. User clicks on PayWithSodexo option for the payment.
  3. The requester’s/merchant’s web site shows below payment options to the user:

    1. Saved Sodexo card

    2. Checkout with a new card

      Note

      The flow remains the same for both options except for the fact that user needs to enter the card details if he/she chooses to go with the "checkout with a new card" option. 

      Let’s assume user chooses to go with "checkout with a new card" option.

  4. The requester’s/merchant's server makes a Create a Transaction with SourceInfo API call to Zeta and in return gets redirectUserTo URL (a Zeta domain secured page where user completes the authorization of the transaction).
    The authorization step is completed in Zeta’s secured domain.
    1. In case of a Saved Card Flow (scenario where the card is already saved with merchant): the requester will initiate the transaction by calling Create a Transaction API along with the sourceId of the saved card. This sourceId is the tokenized card identifier available with the requester. Even in case of ‘payment using saved card’ flow the merchant gets back the redirectUserTo URL.
  5. The requester/merchant redirects the user to redirectUserTo page to complete the authorization. 
  6. The user enters the card number, CVV and expiry date on merchant hosted page. User also chooses whether to allow saving of the card for the convenience of future transactions. For this the merchant needs to expose a toggle button which collects user’s permission - whether to allow saving of the card for future transactions. See the mobile/web flow below:

  7. User gets redirected to the Zeta hosted authorization page where he/she is prompted to enter the PIN, based on the issuer of the card. User enters the PIN and submits. This step completes the transaction authorization. See the mobile/web flow below:

  8. Based on authorization success or failure the user gets redirected to requester’s/merchant’s successUrl or failureUrl. See the mobile/web flow of success and failure scenarios below:
     

  9. In above redirection, the requester gets the "q=<xxxxx>" as a query parameter. The requester/merchant calls Get Transaction Details API to validate the transaction state and transaction amount for the transaction created with requestId = xxxxx.

    Note

    If the user has chosen to "save the card" in step 6, Get Transaction Details response will also return the sourceId that can be saved and used for future transactions.


  10. After successful validation, the merchant/requester should consider the transaction is completed.
Note
  • It’s important to note that Zeta does not prompt the user to enter CVV details again, if the user chooses to do a transaction with a saved card.
  • It’s recommended for merchants to use the SaveCard-based flow for future convenience of the users. This requires the merchant to save the sourceId returned by Zeta and use the same in subsequent transaction requests.
  • The card info (cardNumber, expiry and CVV) is not allowed to be stored on merchant’s system. The tokenized version of card details viz. sourceId is sufficient to get the future transactions supported.
  • Once the merchant has a saved source for the user, he can make a transaction with that source using the Create a Transaction API which is part of the general document.

Save Card Flow

  1. User clicks on "Save Sodexo Card" button on merchant’s/requester’s website.

  2. The merchant’s/requester’s server makes a ‘Save a Card’ API call and in return gets redirectUserTo URL (a Zeta domain secured page where user completes the card authentication process) .

  3. The requester/merchant redirects the user to "redirectUserTo" page.

  4. The user enters the card number, cvv2 and expiry date.

  5. User gets redirected to ACS page where he/she is prompted to enter the card/super card PIN based on the issuer of the card. User enters the PIN and submits it. This step completes the authentication.

  6. Based on authentication success or failure the user gets redirected to requester’s/merchant’s successUrl or failureUrl.

  7. In above redirection, the requester gets the ‘q=<xxxxx>’ as a query parameter. The requester/merchant calls "Get Transaction Details" API with requestId = xxxxx. 
    This returns the sourceId which can be saved for future to get the maskedPan details, balance and other info by calling the "Get a Source" API.

Note

Save card flow debits Rs 0.01 from the user’s account.



Panel


Div
classalignLeftIcon

On this page:

Table of Contents