Skip to main content
This page is part of the Payments Library Guides. For what your backend does after capture, like charging stored tokens and refunds, see the REST API Guides.
Prerequisites: Complete the Library Setup first. All payment methods return results through the same callback function. This page covers how to parse results, check for success, and handle different payment types.

Parsing Results

Use parseResultToken() to decode the result token:
The method returns a tuple:
  • data - The parsed result object
  • success - Boolean indicating if the token was decoded (not whether payment succeeded)

Checking Payment Success

Always check clientSuccess first:

Result Types

Results vary based on the payment method used:

PSP Results (CardPay, Apple Pay, Google Pay)

Card-based payments return results through upgChargeResults:
Available fields:

Decline Reasons

Every gateway words its declines differently. rejectReasonCode normalizes them, so you can react to a decline without writing gateway-specific parsing. It is None when nothing was rejected.
For scheduled payments, this field tells you whether to chase the customer for a new card or simply let the next scheduled attempt run. CardExpired and InvalidCard need the customer; InsufficientFunds and TechnicalError usually do not.
Do not retry Fraud or LostOrStolenCard. Repeated attempts against a blocked card can affect your standing with the issuer.
upgChargeResults is always a single object holding the final gateway attempt. If your account has a gateway fallback chain and earlier attempts failed, those failed attempts are returned separately as an array in failedUpgChargeResults. When there was only one attempt, failedUpgChargeResults is null.

Direct Results (PayPal, BankPay, UPI)

Redirect-based payments return results through directChargeResults:

Tokenization Results

When using TOKENIZE, CHARGE_AND_TOKENIZE, or PREAUTH_AND_TOKENIZE, card details are returned in tokenAndMaskedCardModel:
Persist these non-sensitive fields alongside the token if you plan to offer stored-card payments later - they are needed to display the saved card, and cannot be retrieved afterwards.

Complete Example

Server-Side Validation

Always validate results on your server before fulfilling orders:

Getting Selected Payment Method

Use getSelectedProviderName() to know which payment method the customer used:

Library Reference

Full API reference

Complete Example

End-to-end integration

Start Session API

Create a session token

Validate Results API

Server-side validation endpoint