Payment Method Definition

📓

displayedPaymentMethods

It is a parameter in the Intent creation request that defines which payment method should be displayed to the payer on the checkout form. It is an alternative to paymentMethodName in host-to-host integration

This parameter is provided in: paymentIntent.formDetails.displayedPaymentMethods

⚠️

Currently, only one payment method can be specified. Support for multiple payment methods will be added in the future.

Payment Method Features

Workflow

📗

Auto-Capture: always ON

• When our Checkout Form integration is used, capture is initiated automatically immediately after successful authorisation.
• As a result, manual capture and cancellation flows are not supported for payments processed through the Checkout Form.
• If you need to reverse a completed transaction, please use the standard refund flow via Host-to-Host integration.

Download in high resolution

Create Intent Request

Specifics

• We use one unified Intent creation request for all supported payment methods: POST /processing/api/v1/intents
• The overall structure is the same, but some fields change depending on the payment method and the way of integration: Host-to-Host or Hosted Checkout.
  • For Host-to-Host we will expect you to complete Payment object
  • For Hosted Checkout we will expect you to complete PaymentIntent object
• The required fields depend on the selected method, so this section must be completed carefully.
• The key difference is which object you provide in the request and at what stage the actual payment is created

'Intent' vs 'Payment' vs 'PaymentIntent'

Some objects and parameters in this API may appear similar, but they represent different concepts and are used in different integration scenarios. The explanation below clarifies the purpose of each term.

Request/Response Description

{
  "clientReferenceId": "1234",
  "useCheckoutForm": true,
  "paymentIntent": {
    "formDetails": {
      "template": "string",
      "displayedPaymentMethods": ["Card"],
      "backToStoreRedirectUrl": "string"
    },
    "submittedAmount": {
      "value": 100.05,
      "currency": "USD"
    },
    "description": "Vertex - INTENT 1234",
    "webhookUrl": "webhookUrl",
    "payer": {
      "firstname": "Jake",
      "lastname": "Yellow",
      "phone": "+62285128011",
      "email": "[email protected]",
      "countryIsoCode": "PH",
      "locale": "de-DE",
      "taxIdentification": "798154336790",
      "merchantPayerReference": "12345"
    },
    "payee": {
      "firstNameLocal": "Иван",
      "lastNameLocal": "Иванов",
      "firstNameEng": "Ivan",
      "lastNameEng": "Ivanov",
      "dateOfBirth": "1985-02-14",
      "placeOfBirth": "Smolensk",
      "nationality": "RU",
      "occupation": "Software Engineer",
      "idType": "PASSPORT",
      "idNumber": "AA1234567",
      "taxId": "123456789",
      "currentAddress": {
        "country": "RU",
        "city": "Smolensk",
        "addressLine": "Minusinskaya st., 6, 10",
        "postCode": "720001"
      },
      "email": "[email protected]",
      "phone": "+79001234567",
      "companyName": "ABC Ltd.",
      "companyRegistrationNumber": "987654321",
      "companyTaxId": "321654987",
      "companyRegisteredAddress": "Smolensk, Minusinskaya st., 6",
      "merchantPayeeReference": "12345",
      "additionalData": {
        "customField": "customValue"
      }
    }
  },
  "description": "Vertex - INTENT 1234",
  "merchant": {
    "name": "Mustermann",
    "website": "website.io"
  }
}

Webhooks

🔗

• After the checkout form is created, the payer can make multiple payment attempts during the payment session lifetime.
• By default, the session remains active for 20 minutes, although this value can be changed by your integration manager.
• Each payment attempt creates a new payment object within the intent.
• The platform sends webhooks to the URL provided in paymentIntent.webhookUrl from the request whenever the status of any payment changes.
• This applies to all payment attempts created within the same intent.

For more information about payment webhooks, see the dedicated page

Testing in Sandbox

The bank card emulator simulates the full Checkout payment lifecycle in the sandbox environment. Use the test cards below to reproduce specific authorisation and capture outcomes.

⚠️

Use the listed test cards only. The card number is entered by the payer on the checkout page, after the Intent has been created. If the payer enters a card that is not on this list, authorisation will fail. Cards from the list are the only ones guaranteed to drive the emulator through a complete flow.

What the Checkout emulator covers

• Available in the sandbox environment only.
• Immediate capture is performed automatically after a successful authorisation. Manual capture and cancellation are not applicable to Checkout — any client settings related to capture mode are ignored.
• The flow (Frictionless or Challenge) and the outcome at each stage are determined by the PAN only. Expiry date, CVV, and cardholder name do not affect emulator logic — any values that pass form validation are accepted.
• Amount and currency do not affect emulator behaviour.

Frictionless flow

Authorisation completes without a 3DS challenge. The payer enters card details on the checkout page, and the payment is authorised and captured immediately.

Test cards

Name	PAN	Authorisation	Capture
FF_Card_1	4462603043025620	Success	Success
FF_Card_2	4462603040971339	Success	Failure
FF_Card_3	4462603042343024	Failure	Not applicable