Integration GuideAPI Reference
Integration Guide
๐Ÿ“˜

"displayedPaymentMethods": "UPI

Payment Method Features

FeatureDescription
CountryIndia
Processing CurrenciesINR - Indian Rupees
PaymentsYes
DisbursementsNo
-- Min per transaction amount1 INR
-- Max per transaction amount100,000 INR
RefundsYes
ChargebacksNo

Workflow: Payment & Refund

Download in high resolution

Possible Payment Scenarios:

Our API will provide you with all the necessary information to execute on of the following scenarios:

Name

Steps

Displaying a QR Code in a Web Browser

  1. The client initiates a payment.

  2. The system returns a link to the checkout page on the platform.

  3. The client is redirected to the checkout page on the platform.

  4. The user enters the required payment details and clicks the payment button.

  5. The system displays a QR code for scanning by the UPI app.

  6. The end user scans the QR code with a mobile device and is redirected to the mobile app for payment.

  7. The payment status is returned via a callback.

Payment via Mobile Application

  1. The client initiates a payment.

  2. The system returns a link to the checkout page on the platform.

  3. The client is redirected to the checkout page on the platform.

  4. The user enters the required payment information and clicks the payment button.

  5. The system displays a list of apps for the user to navigate to.

  6. The user completes the payment in their app.

  7. The payment status is returned via a callback.


List of used API Requests:

Request

Endpoint

Description

Intent Creation

POST /processing/api/v1/intents

  • Creates a new Intent and returns the URL for redirection to the platform checkout

Intent Creation Request/Response

๐Ÿ“˜

Request specifics

  • Endpoint: POST /processing/api/v1/intents
  • Purpose: Creates an Intentfor the selected payment method.
  • Structure: A unified request structure is used for all supported payment methods.
  • For this method:
    • The paymentIntent object is populated
    • paymentIntent is populated with true
    • The paymentIntent.formDetails.displayedPaymentMethods array contains the UPI
    • The following optional fields are recommended for populating:
      • paymentIntent.description
      • paymentIntent.payer.firstname
      • paymentIntent.payer.lastname
      • paymentIntent.payer.taxIdentification

Request Description

{
  "clientReferenceId": "1234",
  "useCheckoutForm": true,
  "paymentIntent": {
    "formDetails": {
      "template": "string",
      "displayedPaymentMethods": ["UPI"],
      "backToStoreRedirectUrl": "string"
    },
    "submittedAmount": {
      "value": 100.05,
      "currency": "INR"
    },
    "description": "INTENT 1234",
    "webhookUrl": "webhookUrl",
    "payer": {
      "firstname": "Jake",
      "lastname": "Yellow",
      "taxIdentification": "AAAPZ1234C"
    },
    "payee": {}
  },
  "description": "INTENT 1234",
  "merchant": {
    "name": "Mustermann",
    "website": "website.io"
  }
}

Top-Level Request Parameters

ParameterTypeRequiredDescription
clientReferenceIdStringRequiredOrder number in the merchant system.
useCheckoutFormBooleanConditionalOptional in general.
Must be set to true when using the Checkout Form integration.
paymentIntentObjectConditionalOptional in general.
Must be provided when using the Checkout Form integration.
descriptionStringOptionalOrder description.
Displayed if paymentIntent.description is not provided.
merchantObjectOptionalMerchant information.
Required if the store name must be displayed on the checkout form.


paymentIntent

ParameterTypeRequiredDescription
formDetailsObjectOptionalCheckout parameters
submittedAmountObjectRequiredOrder amount and currency
descriptionStringOptionalOrder Description that can be displayed on the Checkout Form.
webhookUrlStringRequiredURL to which we will send webhooks related to payments created within the Intent and their status changes
payerObjectOptionalPayer (consumer) details. May be used to pre-fill the checkout form and for compliance/risk purposes.
payeeObjectOptionalPayee (recipient/beneficiary) details. Used for compliance and reporting purposes when applicable.


formDetails

ParameterTypeRequiredDescription
templateStringOptionalThe name of the checkout template to be used.
Multiple templates can be configured and selected for different use cases
displayedPaymentMethodsArray of StringsOptionalList of payment methods to be made available to the payer.
If only one payment method is provided, no selection screen is shown and the payer is taken directly to that payment method
backToStoreRedirectUrlStringOptionalURL to which the payer is redirected if they leave the Checkout Form or after payment completion. Must start with "https://".


submittedAmount

ParameterTypeRequiredDescription
valueNumberRequiredSubmitted order amount.
May differ from the authorised amount if FX conversion is applied.
currencyStringRequiredSubmitted order currency.

May differ from the authorised amount if FX conversion is applied.


payer

ParameterTypeRequiredDescription
firstnameStringOptionalPayer's first name.
Example: Jake
lastnameStringOptionalPayer's last name.
Example: Yellow
phoneStringOptionalPayer's phone number, including country code.
Example: +62285128011
emailStringOptionalPayer's email address.
Example: [email protected]
countryIsoCodeStringOptionalPayer's country of residence in ISO 3166-1 alpha-2 format.
Example: PH
localeStringOptionalThe locale describing the preferred language of the consumer. Used to localise the checkout form when supported.
Example: de-DE
taxIdentificationStringOptionalThe consumer tax identification number (e.g., social security identification). Required by some payment methods or jurisdictions.
Example: 798154336790
merchantPayerReferenceStringOptionalThe merchant-provided payer reference. Allows linking the payer to an internal customer record on the merchant side.
Example: 12345


payee

ParameterTypeRequiredDescription
firstNameLocalStringOptionalPayee's first name in the local language.
Example: ะ˜ะฒะฐะฝ
lastNameLocalStringOptionalPayee's last name in the local language.
Example: ะ˜ะฒะฐะฝะพะฒ
firstNameEngStringOptionalPayee's first name in English.
Example: Ivan
lastNameEngStringOptionalPayee's last name in English.
Example: Ivanov
dateOfBirthStringOptionalPayee's date of birth in YYYY-MM-DD format.
Example: 1985-02-14
placeOfBirthStringOptionalPayee's place of birth.
Example: Smolensk
nationalityStringOptionalPayee's nationality in ISO 3166-1 alpha-2 format.
Example: RU
occupationStringOptionalPayee's occupation.
Example: Software Engineer
idTypeStringOptionalType of identification document presented by the payee (e.g., PASSPORT, ID_CARD).
Example: PASSPORT
idNumberStringOptionalIdentification document number that matches the idType.
Example: AA1234567
taxIdStringOptionalPayee's personal tax identification number.
Example: 123456789
currentAddressObjectOptionalPayee's current residential address. See the currentAddress table below for the field structure.
emailStringOptionalPayee's email address.
phoneStringOptionalPayee's phone number.
companyNameStringOptionalName of the company the payee represents (when the payee is a legal entity).
Example: ABC Ltd.
companyRegistrationNumberStringOptionalRegistration number of the payee's company.
Example: 987654321
companyTaxIdStringOptionalTax identification number of the payee's company.
Example: 321654987
companyRegisteredAddressStringOptionalRegistered legal address of the payee's company.
merchantPayeeReferenceStringOptionalThe merchant-provided payee reference. Allows linking the payee to an internal record on the merchant side.
Example: 12345
additionalDataObjectOptionalFree-form key/value object for any additional payee details required by specific payment methods or compliance rules.


payee.currentAddress

ParameterTypeRequiredDescription
countryStringOptionalCountry of the address in ISO 3166-1 alpha-2 format.
Example: RU
cityStringOptionalCity.
Example: Smolensk
addressLineStringOptionalStreet address line.
Example: Minusinskaya st., 6, 10
postCodeStringOptionalPostal / ZIP code.
Example: 720001


merchant

ParameterTypeRequiredDescription
nameStringOptionalThe name of store, that might be displayed on the checkout form if configured
websiteStringOptionalThe website of the store


Refunds

๐Ÿ“˜

Refunds cannot exceed the total value of confirmed transactions for the current day.

To initiate the refund (full or partial) to the payer's original payment instrument, you must send a separate Refund request.

Use the following endpoint: Create Refund and specify the following parameters:


{
  "paymentId": 204264682781298700,
  "partial": false,
  "reason": "Customer requested a refund",
  "webhookUrl": "webhookUrl"
}
{
  "paymentId": 204264682781298700,
  "partial": true,
	"paymentAuthAmount": {
    "value": 100.05,
    "currency": "INR"
  },

  "reason": "Customer requested a refund",
  "webhookUrl": "webhookUrl"
}

Refund amount rules

RuleDescription
Full refundSend paymentId and set partial to false, or omit partial entirely. The full refundable amount will be refunded.
Partial refundSet partial to true and provide exactly one of the following objects: paymentSubmittedAmount or paymentAuthAmount.
Mutually exclusive amount objectsDo not send paymentSubmittedAmount and paymentAuthAmount in the same request.
FX paymentsIf the original payment involved FX conversion, the refund is calculated using the same exchange rate as the original payment.
Currency choiceUse paymentSubmittedAmount if you want to define the refund in the original submitted currency.
Use paymentAuthAmount if you want to define the refund in the authorised or settlement currency.

Top-Level Refund Request Parameters

ParameterTypeRequiredDescription
paymentIdint64RequiredIdentifier of the original payment transaction to which this refund applies.
Use the paymentId returned in the original payment or Intent creation response.
partialBooleanOptionalIndicates whether the refund is partial or full.
true - partial refund.
false - full refund.
If omitted, the platform treats the request as a full refund.
paymentSubmittedAmountObjectConditionalRefund amount in the original submitted currency.
Required when partial = true and the refund amount is defined in the submitted currency.
Do not send together with paymentAuthAmount.
paymentAuthAmountObjectConditionalRefund amount in the authorised or settlement currency.
Required when partial = true and the refund amount is defined in the authorised currency.
Do not send together with paymentSubmittedAmount.
reasonStringOptionalFree-form refund reason.
Used for informational and audit purposes.
webhookUrlStringOptionalURL to which refund status change webhooks will be sent.

paymentSubmittedAmount

ParameterTypeRequiredDescription
valueNumberRequiredRefund amount value in the original submitted currency.
currencyStringRequiredRefund currency in ISO 4217 alpha-3 format.
Must match the original submitted currency.

paymentAuthAmount

ParameterTypeRequiredDescription
valueNumberRequiredRefund amount value in the authorised or settlement currency.
currencyStringRequiredRefund currency in ISO 4217 alpha-3 format.
Must match the original authorised or settlement currency.

After the creation of the refund request you must wait for the callback, that will provide you with the latest transaction status


Webhooks

๐Ÿ”—

This section summarises the webhook events triggered for UPI payment.
For payload structure, examples, retry policy and delivery conditions, see the dedicated pages: Webhooks: Overview and Webhooks: Example.

When Webhooks Are Sent

A webhook is dispatched to your webhookUrl when the payment reaches a final status:

StatusTrigger
CAPTUREDThe payment has been successfully completed.
DECLINEDThe payment was rejected by the issuing bank / processor.
ERRORA processing error prevented the payment from being completed.

Delivery & Retries

๐Ÿ“˜
  • Webhooks are delivered as HTTPS POST requests with a JSON payload to the webhookUrl provided in the original disbursement request.
  • A delivery is considered successful if your endpoint responds with HTTP 2xx.
  • If the delivery fails (non-2xx, network error, timeout), the platform retries up to 10 times following a fixed schedule (immediate โ†’ 1 min โ†’ 5 min โ†’ 15 min โ†’ 1 h โ†’ 3 h โ†’ 6 h โ†’ 12 h โ†’ 24 h โ†’ 48 h).
  • After the 10th attempt, delivery stops permanently.

Full details: Webhooks: Overview.

Payload Example

๐Ÿ““

The webhook payload structure is shared across all transaction types and may evolve over time.
For the up-to-date payload example, see the Webhooks: Example page.


Testing in Sandbox

๐Ÿ“˜

Our test environment allows us to simulate the full payment cycle and run all possible final status options without the involvement of a real bank and payment application. To force a specific outcome, set the intent.description field to one of the trigger values below.


List of Test Scenarios

Scenariointent.description ValueFinal Status
Successful paymentCapturedPaymentShortCAPTURED
Declined. paymentDeclinedPaymentShortDECLINED
Processing errorErrorPaymentShortERROR

End-to-End Test Flow

Download in high resolution


Step-by-Step Scenario Description

Scenario

Steps

Successful payment

  1. Create an paymentIntent viaย POST /processing/api/v1/intentsย withย intent.description = "CapturedPaymentShort".
  2. Receive a synchronous response withย intentStatus = CREATEDand with a URL to redirect to the checkout page in paymentIntent.additionalData.details.url parameter
  3. Our platform simulates the successful creation of a payment.
  4. Receive a webhook withย status = AUTHORIZATION_REQUESTED.
  5. Our platform simulates the successful completion of a payment.
  6. Receive a final webhook withย status = CAPTURED.

Declined. payment

  1. Create an paymentIntent viaย POST /processing/api/v1/intentsย withย intent.description = "DeclinedPaymentShort".
  2. Receive a synchronous response withย intentStatus = CREATEDand with a URL to redirect to the checkout page in paymentIntent.additionalData.details.url parameter
  3. Our platform simulates the successful creation of a payment.
  4. Receive a webhook withย status = AUTHORIZATION_REQUESTED.
  5. Our platform simulates a payment refusal.
  6. Receive a final webhook withย status = DECLINED.

Processing error

  1. Create an paymentIntent viaย POST /processing/api/v1/intentsย withย intent.description = "ErrorPaymentShort".
  2. Receive a synchronous response withย intentStatus = CREATEDand with a URL to redirect to the checkout page in paymentIntent.additionalData.details.url parameter
  3. Our platform simulates an error when creating a payment.
  4. Receive a final webhook withย status = ERROR.