About the Method

BankCardUZ accepts cards of HUMO and UZCARD — the two national payment schemes of Uzbekistan. Virtually every card issued by Uzbek banks belongs to one of these schemes, which makes this method the primary way to accept card payments from customers in Uzbekistan.

Key characteristics of the local schemes to keep in mind:

• All payments are processed in Uzbek soum (UZS).
• Instead of the classic 3-D Secure flow, the payer confirms the payment with an SMS code sent by their bank. The confirmation step is requested for virtually every payment — do not design your flow around a "no confirmation" scenario.
• A security code (CVV/CVC) may be absent on HUMO/UZCARD cards — it is optional for this method.
• Payments are processed in a single step: authorisation and funds withdrawal happen together. There is no authorisation hold stage.

The payment follows the standard card flow of our platform: after the Intent is created, you redirect the payer to the URL returned in the response. The payer briefly lands on our hosted page where the required payer metadata is collected, and is then routed automatically — either straight back to your store (frictionless) or to the SMS confirmation form first (challenge).

Payment Method Features

Possible Payment Scenarios:

Name	Steps
Payment with SMS confirmation (Challenge)	1. You send an Intent creation request via the API, including a Payment transaction. 2. Our platform validates the incoming data, initiates the payment and returns the redirect URL in payments[].additionalData.details.url. 3. You redirect the payer to this URL. Our hosted page collects the required payer metadata. 4. [Confirmation is required] The payer is presented with the confirmation form and enters the SMS code sent by their bank. 5. Our platform receives the confirmation result and completes the payment: the funds are withdrawn in a single step. 6. The payer is redirected back to your redirectUrl. 7. Our platform sends a webhook with the final payment status: CAPTURED or DECLINED.
Payment without confirmation (Frictionless)	For this method the confirmation step (challenge) is requested for virtually every payment — frictionless scenario can be applied only for cobranded cards (with Visa or Mastercard) where the network considers the transaction safe. 1. You send an Intent creation request via the API, including a Payment transaction. 2. Our platform validates the incoming data, initiates the payment and returns the redirect URL in payments[].additionalData.details.url. 3. You redirect the payer to this URL. Our hosted page collects the required payer metadata. 4. [Confirmation is not required] The payer is redirected back to your redirectUrl without any additional steps. 5. Our platform completes the payment and sends a webhook with the final status: CAPTURED or DECLINED.

List of used API Requests:

Intent Creation Request/Response

{
  "clientReferenceId": "1234",
  "payments": [
    {
      "paymentInstrument": {
        "paymentMethodName": "BankCardUZ",
        "incomingDetails": {
          "number": "9860XXXXXXXXXXXX",
          "expiryMonth": "10",
          "expiryYear": "2028",
          "holderName": "JOHN DOE",
          "redirectUrl": "https://merchant.example.com/payment/return"
        }
      },
      "submittedAmount": {
        "value": 100000.00,
        "currency": "UZS"
      },
      "authCurrencyCode": "UZS",
      "description": "Vertex - INTENT 1234",
      "webhookUrl": "https://merchant.example.com/webhooks"
    }
  ],
  "description": "Vertex - INTENT 1234"
}

{
  "intentId": "232510340021612544",
  "payments": [
    {
      "id": "232510340646563840",
      "submittedAmount": {
        "value": 100000.00,
        "currency": "UZS"
      },
      "authAmount": {
        "value": 100000.00,
        "currency": "UZS"
      },
      "paymentInstrument": {
        "id": "PI204264628196626432",
        "paymentMethodId": "PM199507277233246209",
        "paymentMethodName": "BankCardUZ",
        "storedDetails": {
          "number": "9860XXXXXXXXXXXX",
          "expiryMonth": "10",
          "expiryYear": "2028",
          "holderName": "JOHN DOE",
          "redirectUrl": "https://merchant.example.com/payment/return"
        }
      },
      "processingStatusCode": "CODE_PT0000",
      "statusMessage": "string",
      "status": "AUTHORIZATION_REQUESTED",
      "additionalData": {
        "details": {
          "url": "https://redirect.url.example/..."
        }
      }
    }
  ],
  "disbursements": [],
  "clientReferenceIntentId": "1234",
  "paymentCreationErrors": [],
  "disbursementCreationErrors": [],
  "intentStatus": "IN_PROGRESS"
}

Payment Confirmation

• Always redirect the payer to the URL returned in payments[].additionalData.details.url. Our hosted page collects the required payer metadata and routes the payer automatically: back to your store (frictionless) or to the confirmation form first (challenge).
• On the confirmation form the payer enters the SMS code sent to the phone number linked to their card.
• After the payer completes (or abandons) the flow, they are redirected back to your redirectUrl.
• The redirect to redirectUrl does not carry the payment result. The final status (CAPTURED or DECLINED) is delivered via webhook — always rely on the webhook, not on the payer's return.

Refunds

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": 232510340646563840,
  "partial": false,
  "reason": "Customer requested a refund",
  "webhookUrl": "https://merchant.example.com/webhooks"
}

{
  "paymentId": 232510340646563840,
  "partial": true,
  "paymentAuthAmount": {
    "value": 30000.00,
    "currency": "UZS"
  },
  "reason": "Customer requested a refund",
  "webhookUrl": "https://merchant.example.com/webhooks"
}

After the creation of the refund request you must wait for the webhook that will provide the latest refund status.

Webhooks

Testing in Sandbox

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

What the H2H emulator covers

• Available in the sandbox environment only.
• 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 validation are accepted.
• Amount and currency do not affect emulator behaviour.
• For this method the payment completes automatically after a successful confirmation — no additional client action is required at any stage.

Payment flows

Regardless of the flow, the payer must briefly land on our hosted page so we can collect the required payer metadata. The client redirects the payer to the URL returned in the Intent creation response. After metadata collection, the payer is routed according to the flow determined by the PAN:

• Frictionless — the payer is redirected back to the merchant storefront via redirectUrl, and the payment result is delivered via webhook.
• Challenge — the payer is presented with the SMS confirmation form before being redirected back to the merchant. In the live environment, virtually every payment of this method follows the Challenge flow.

Challenge flow (SMS confirmation)

After metadata collection, the payer is presented with the confirmation form. The code value entered by the payer determines the outcome.

Test cards and confirmation codes

Name	PAN	Code	Final payment status
CF_Card_1	5120069996100821	1000	CAPTURED
CF_Card_2	5120069996491832	1000	DECLINED — confirmation succeeds, but the funds withdrawal fails
Either of the above	—	1001	DECLINED — confirmation fails

ℹ️

Any code value other than those listed above is not recognised by the emulator. The payment will not progress and will remain in the AUTHORIZATION_REQUESTED state.