Unknown macro: {style}

.page-metadata

Unknown macro: {display}

Page tree
Skip to end of metadata
Go to start of metadata

Overview

This article serves as an integration guide for developers/product managers of any business who wish to use Zeta money as a payment instrument on their user payment flows. A successful integration using PWZ RESTful APIs helps you securely accept E-com based payments from Zeta users.

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

Integration Methods

PayWithZeta can be integrated using the Checkout Flow and Save Source Flow. The details of each flow is described below. 

Before You Begin

Take care of the following:

Checkout Flow

  1. User adds items to the cart on the e-commerce application and goes to the checkout page.
  2. User clicks on PayWithZeta option for the payment.
  3. The requester’s/merchant's server creates a transaction on Zeta and in return gets redirectUserTo URL (this is a Zeta domain page where user completes the authorization of the transaction). Post this the authorization step is completed in Zeta’s domain.
    1. In case of already Saved Source: the Create a Transaction API call needs to be called with value of parameter sourceId. This sourceId is an identifier of tokenized source available with the requester.
    2. In case of a New Source: Merchant can call any of the below APIs based on scenario:
      1. If the merchant wants to collect phone number of the user in their domain then the transaction can be created using Create transaction with SourceInfo API.
      2. If the merchant wants to use Zeta’s default phone number entry page, then the merchant can call the Create a Transaction API. This API call should have sourceId as null.
  4. The requester/merchant redirects the user to "redirectUserTo" page to complete the authorization.
  5. User enters the Zeta registered phone number. User can also choose whether to allow saving of details for future transactions.

    This step will be skipped if merchant has already followed Step 3a or 3b[i].


  6. User is redirected to User Authentication page in Zeta domain where he/she is prompted to enter the OTP (which is automatically sent to the user when they land on the User Authentication page) or Zeta Super Pin. User enters the OTP (or Super Pin) and submits it to complete transaction authentication and authorization.
  7. Based on authorization success or failure, the user is taken to Zeta’s success or failure page. Post this the user gets redirected to requester’s/merchant’s successUrl or failureUrl.
     
  8. 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. Only after successful validation, the merchant/requester should consider the transaction is completed.
  9. If the user has chosen to "save for future" (Coming soon in future update) in step 6, Get Transaction Details response will also return the sourceId that can be saved and used in future transactions.

Save Source Flow

  1. User clicks on "Save Payment Instrument" button on merchant’s/requester’s website.

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

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

  4. The user enters the authentication details (phone number and OTP received on the registered phone number)

  5. User gets redirected to ACS page in Zeta domain where he/she is prompted to enter the OTP (which is automatically sent to the user when they land on the ACS page). User enters the OTP and submits it to complete the authentication process.

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

  7. In the above redirection, the requester gets the ‘q=<xxxxx>’ as a query parameter. The requester/merchant calls Get a Source API with saveSourceRequestId = xxxxx and this returns the sourceId which can be saved and used for future transactions.

On this page: