Integration Steps

The following steps are involved in integrating Paze checkout to a native mobile application:

Call Paze /token API: Authentication endpoint to retrieve an OAuth access token that is used for the following API endpoints. The details for this API are documented in thePaze Platform_API_OAuth_Acces_User Guide Version_1.3.

Note: The Merchant needs to obtain a separate Paze OAuth access/bearer token per checkout session. Merchants should not attempt to reuse a Paze OAuth token across multiple checkout sessions as doing do will result in an error.

Call /checkout/session/create API: This API is used to create the Paze checkout session. Calling Create creates a checkout session and a Paze Checkout URL is returned in the response.

For checkout flow optimization, the Merchant can include any available consumer email address or mobile number in the Create call. The Paze Service will utilize that information to optimize the checkout flow when possible, such as not showing the email/phone entryscreen if a wallet has been located.

If neither an email nor mobile number is provided or if the provided email or mobile number doesn’t match a wallet. Paze checkout will prompt the consumer for the necessary information to locate their wallet.

Launch the Paze checkout UX (user experience) for card, and possibly shipping address, selection: If the consumer taps the Paze button (or related action), the Merchant launches the Paze checkout URL from the previous step, using the appropriate UX control.

The resultant UX will run the complete Paze consumer-facing checkout flow (including lookup, authentication of consumer, consumer information selection, etc.) and will return information to indicate whether the checkout flow was successfully completed, the user did not complete the checkout flow, or there was some other error, such as a query parameter via the callback URL scheme. If the checkout flow was successfully completed, minimal masked card information and a code is also returned to the Merchant. The Merchant needs to pass that code back to the Paze Service in any subsequent API call.

[Optional] Call /checkout/session/review API: Returns a summary of the consumer's card and shipping address for display on confirmation screen, if one is presented to the consumer.

[Optional] Re-Launch the Paze checkout UX to allow user to change card or shipping address: If the Merchant provides options to the user to change their selected card and/or shipping address, and the consumer taps one of those options, the Merchant needs to launch the Paze UX again, but this time using the appropriate URL returned in a prior response payload in the appropriate UX control as appropriate UX control as specified later.

The resultant UX will run the appropriate consumer-facing change card or change shipping address flow and return information to indicate if the flow was successfully completed, or if the user did not complete the flow, or there was some other failure, as a query parameter via the callback URL scheme. If the flow was successfully completed, a code is also returned to the Merchant. The Merchant needs to pass that code back to the Paze Service in any subsequent API call, such as the /checkout/session/reviewAPI to retrieve the updated information or to /checkout/session/complete API to close the checkout session.

Call /checkout/session/complete API: Closes the Merchant and consumer sessions, and provides payment details required to successfully process the Payment Transaction, including whether the consumer to make a payment immediately, put a card on file with the Merchant, or both. The Merchant can decide to just close the checkout session but not receivethe secure payload via this call and instead retrieve the secure payload via the Get Payload API documented in thePazeMerchant Business to Business APIs TechnicalRequirements guide. The secure payload includes the payment token, cryptogram, expiry date, etc., that can then be used to get a payment authorization from the card network, toswap and to put on file with the Merchant, or both.

Note: /checkout/session/complete must still be called to close the session even if the B2B API is being used to retrieve the secure payload.