A reference of banks, payment channels, and requisite types (card, SBP, IBAN) in Syncra V2

Banks and payment methods

For fine-tuning P2P payment flows, Syncra V2 provides a reference of banks and payment channels. It lets merchants route clients to preferred payment methods to increase conversion. The platform is not tied to a specific country: the reference can include RU/CIS banks (cards, SBP) and international markets (IBAN/BANK_TRANSFER — Turkey, the EU).

Supported banks

The bank list is determined by the tenant configuration and managed by an administrator via the control panel. The current list is available via GET /banks.

Bank examples by market:

System name	Display name	Country	Methods (requisite types)
`sber`	Sberbank	RU	SBP, BANK_CARD
`t-bank`	T-Bank	RU	SBP, BANK_CARD
`ziraat`	Ziraat Bankası	TR	BANK_TRANSFER (IBAN/Havale)
`sepa-bank`	SEPA bank (EU)	EU	BANK_TRANSFER (IBAN/SEPA)

The bank list grows without restarting services. A bank's availability depends on active trader requisites for that bank and requisite type.

Available payment methods

Payment methods define the technical protocol of the payment. Under the hood, each method has a requisite type (RequisiteType) — a country-neutral classification of the payment instrument:

SBP (faster payment system): Transfer by the payer's phone number to the trader's card at any SBP member bank. The highest conversion on the RU market. Requisite type: SBP.
BANK_CARD (card-to-card transfer): A direct transfer by the recipient's 16-digit bank card number. Requisite type: BANK_CARD.
BANK_TRANSFER (international bank transfer by IBAN): A transfer by IBAN (ISO 13616) — the recipient's international account number. Used for markets outside RU/CIS: Havale (Turkey, TRY), SEPA (EU, EUR), and any other bank transfer where the recipient is identified by an IBAN. On the payment page, the client receives the iban, holder_name, and payment_method_name fields; the IBAN is encrypted in Vault with the same transit key as the PAN. Requisite type: BANK_TRANSFER.

The full list of requisite types (BANK_CARD, E_WALLET, SBP, SIM, BANK_TRANSFER) is in Requisite types. The availability of a specific type for your merchant is determined by the merchant → method → currency configuration and requires no integration code changes: a PayIn is created with the same POST /deals/payin endpoint with the right payment_method_id.

Get the bank list via the API

To fetch the dynamic list of available banks with their current activity on the platform (which channels are live right now), use the GET endpoint:

GET /api/v1/p2p/merchant/banks

Query parameters

Field	Type	Required	Description
`country`	string	No	ISO country code to filter by (for example, `"ru"`, `"uz"`).
`currency`	string	No	Payment currency (for example, `"RUB"`).

Request example

GET /api/v1/p2p/merchant/banks?country=ru&currency=RUB

Response example (`200 OK`)

{
  "banks": [
    {
      "bank_name": "sber",
      "display_name": "Sberbank",
      "country": "ru",
      "methods": ["BANK_CARD", "SBP"]
    },
    {
      "bank_name": "t-bank",
      "display_name": "T-Bank",
      "country": "ru",
      "methods": ["BANK_CARD", "SBP"]
    },
    {
      "bank_name": "ziraat",
      "display_name": "Ziraat Bankası",
      "country": "tr",
      "methods": ["BANK_TRANSFER"]
    }
  ]
}

The methods field in the GET /banks response holds requisite types (RequisiteType: BANK_CARD, SBP, BANK_TRANSFER, ...), NOT payment methods and NOT their identifiers. The endpoint returns no UUID. The canonical source of payment_method_id (UUID) is GET /payment-methods.

Get the method catalog via the API

The canonical method catalog of your tenant is the endpoint:

GET /api/v1/p2p/merchant/payment-methods

It returns the active (status: ACTIVE) methods of the merchant's tenant. This is the canonical catalog of method identifiers: the UUID (the id field) and the slug (the slug field) for payment_method_id in POST /deals/payin and for payment_method in POST /deals/payout — both legs of the deal accept both formats (a unified contract; the recommended format is UUID for PayIn, slug for PayOut).

Response example (`200 OK`)

{
  "data": [
    {
      "id": "550e8400-e29b-41d4-a716-446655440000",
      "slug": "express-havale",
      "name": "Havale Express (TRY)",
      "requisite_types": ["BANK_TRANSFER"],
      "currency_code": "TRY",
      "status": "ACTIVE"
    },
    {
      "id": "6ba7b810-9dad-11d1-80b4-00c04fd430c8",
      "slug": "sbp_rub",
      "name": "SBP",
      "requisite_types": ["SBP"],
      "currency_code": "RUB",
      "status": "ACTIVE"
    }
  ]
}

Field	Type	Description
`id`	string(UUID)	Method UUID — the canonical value for `payment_method_id` in PayIn; also accepted as `payment_method` in PayOut.
`slug`	string	Method slug — the canonical value for `payment_method` in PayOut (`sbp_rub`, `card_rub`, `mobcom_rub`, `express-havale`, ...); also accepted as `payment_method_id` in PayIn. Slugs are identical across all environments (stage/prod) and never change over time.
`name`	string	The method's display name.
`requisite_types`	string[]	The requisite types (`RequisiteType`) the method serves. An informational field: it shows which trader requisites will be issued to the client (an SBP phone, a card, a SIM, an IBAN, a wallet number) — it is not passed in PayIn/PayOut requests.
`currency_code`	string	The method's ISO 4217 currency (from the tenant's currency reference). The method currency must match the deal currency (PayOut checks this and answers 400).
`status`	string	`ACTIVE` or `DISABLED`. `DISABLED` — the method is off for your merchant: payin/payout returns `400` (managed by the platform operator, enabled on request). Other statuses are filtered out.

Take method identifiers from this catalog at runtime (with caching) — new methods will then appear in your GET /banks automatically, with no code changes. Both formats (id/UUID and slug) are accepted on both legs of the deal; the recommended pairs are PayIn → id (UUID), PayOut → slug.

Automatic filtering and cascades

The GET /banks response is built from the tenant's active methods (p2p_payment_methods.status = ACTIVE) with country/currency filters — a bank never "temporarily disappears" from the reference when traders exhaust their daily limits (the availability of a specific trader/requisite affects deal matching, not the bank reference).
The system distributes the incoming payment flow across partner-bank cards / IBAN accounts to prevent blocks, which extends the lifetime of payment requisites. This applies to all requisite types — BANK_CARD, SBP, E_WALLET, SIM, BANK_TRANSFER.

Banks and payment methods

On this page