Payment methods

A payment method code names the rail a payment or transfer moves over - a card, a bank debit, a local wallet, a cash voucher. You send it as payment_method.code when you create a payment or a transfer, and it comes back as payment_method on the resulting order and transactions. Codes are snake_case strings; lowercase is canonical and requests accept any case (see Conventions).

This page lists every code the Merchant API knows, grouped by family. It is the companion to the PaymentMethodCode schema in the API reference.

Where the code appears

Field	Direction	Where
`payment_method.code`	Request	`POST /v1/payments` (direct payments) and `POST /v1/transfers` (transfers). Required.
`payment_method`	Response	Transaction and Order objects returned by the search, get, and by-reference endpoints. `null` while unknown.
`payment_method`	Webhook	Payment event payloads.
`code`	Response	`GET /v1/payment-methods` and `GET /v1/payment-methods/{code}/fields` - the methods you can charge in a given context, with the body fields each needs (discovery).

A checkout session takes no code when you create it - the customer picks a method on the hosted page, and the chosen code then appears on the resulting order and transactions.

Two umbrella codes

card covers every card scheme. The scheme is detected from the card number, so you never send visa or mastercard. See Card payments.
bank covers every regional bank-transfer rail (SEPA, Faster Payments, ACH, SPEI, Zengin…). The provider you route to maps it to the concrete rail from the currency, country, and account fields you supply. See Transfers.

Availability

Being on this page does not mean a code is live on your account. A method works only when a provider channel configured on your account supports it for the transaction's country and currency; the catalog below is the superset across all providers. Which methods you can offer is agreed during onboarding; to see what is live for a given country and currency right now - and which fields each method needs - call GET /v1/payment-methods.

The errors you will see when a code is not usable:

Error code	Meaning
`unknown_payment_method`	The code is not one listed on this page.
`payment_method_not_supported_by_provider`	The code exists, but the provider your request routed to does not support it.
`payment_unroutable`	No provider channel on your account can take this method for this country and currency.

Discovering methods and required fields

Which methods are live on your account for a given country and currency is decided by your routing configuration - and so is which POST /v1/payments body fields each one needs, because different providers ask for different customer details. Rather than hard-code either, ask the API:

Endpoint	Returns
`GET /v1/payment-methods?country=BR&currency=BRL&amount=150.00`	Every method you can charge in that context, each with its `required_fields`.
`GET /v1/payment-methods/{code}/fields?country=BR&currency=BRL&amount=150.00`	The same descriptor for one method. `404 payment_unroutable` when it cannot be routed for you there.

country and currency are required and mean the same as on the payment you are about to create. amount is optional; pass it when you know it, so amount-range routing rules are applied and the primary/fallback split is exact. Both are GETs with no body: sign timestamp + path + "" - the query string is not part of the signed string (see Signing).

REQ_PATH="/v1/payment-methods/pix/fields"
TS=$(date +%s)
SIG=$(printf '%s' "${TS}${REQ_PATH}" \
  | openssl dgst -sha256 -hmac "$UPPROVE_SIGNING_SECRET" | sed 's/^.*= //')

curl -sS "https://api.sandbox.upprove.com${REQ_PATH}?country=BR&currency=BRL&amount=150.00" \
  -H "Authorization: Bearer $UPPROVE_SECRET_KEY" \
  -H "X-Signature: t=${TS}, v1=${SIG}"

{
  "code": "pix",
  "display_name": "Pix",
  "type": "real_time_payment",
  "requires_redirect": false,
  "required_fields": [
    {
      "path": "customer.name",
      "field_type": "text",
      "required": true,
      "reason": "primary",
      "label": "Full name"
    },
    {
      "path": "customer.email",
      "field_type": "email",
      "required": true,
      "reason": "primary",
      "label": "Email"
    },
    {
      "path": "payment_method.details.document_id",
      "field_type": "text",
      "required": true,
      "reason": "primary",
      "label": "National ID number"
    },
    {
      "path": "customer.billing_address.country",
      "field_type": "country",
      "required": false,
      "reason": "fallback",
      "label": "Country"
    }
  ]
}

The list endpoint wraps the same objects in the usual list envelope, unpaged: has_more is always false and there are no page/limit fields. type is the method's family, using the same names as the sections below (card, wallet, real_time_payment, …). requires_redirect is indicative only - always act on the next_action.type the payment response gives you.

Reading `required_fields`

Each entry is one field of the create-payment body, identified by its path (customer.email, payment_method.details.document_id, …), with a field_type you can validate against and a label you can show. What matters is reason:

primary - the provider your payment will be routed to first needs it. required is that provider's rule: leave a required primary field out and POST /v1/payments fails with validation_failed.
fallback - only a provider further down your routing chain needs it. It is always optional. If you send it, the payment can cascade to that provider after the primary declines; if you don't, that fallback is skipped.

A field is listed once - as primary if the primary provider wants it, otherwise as fallback. customer.name and the pair customer.first_name + customer.last_name satisfy each other, so send whichever you hold. card is listed like any other method, but its required_fields is empty: the card itself is collected by Upprove.js after next_action: collect_card (see Card payments), so nothing card-specific belongs in the body.

The answer is resolved against your routing at request time, so it changes when your configuration changes or a provider is temporarily unavailable - a method none of whose channels can currently take the payment is left out of the list and is 404 payment_unroutable on lookup. Cache it briefly at most, and re-check just before you create the payment.

Redirects and next actions

Most non-card methods send the customer away to approve the payment - to their bank, a wallet app, or a hosted page. Do not decide this from the code: the payment response tells you what to do next through next_action.type - redirect, collect_card, qr (e.g. Pix), voucher (e.g. OXXO, Boleto), bank_transfer (e.g. SPEI), or three_ds_challenge. See Direct payments and the NextAction schema in the API Reference.

Identity documents for LATAM methods

For pix, boleto, spei, oxxo, and pse, pass the paying customer's national identity document in payment_method.details.document_id - the CPF in Brazil, CURP or RFC in Mexico, cedula in Colombia. The payment is rejected with a validation error when it is missing or malformed for the method's country. See the note in Direct payments.

Payments vs transfers

A transfer uses the same payment_method.code, but there it names the destination rail rather than the way a customer pays. The accompanying payment_method.details describes the destination payment instrument - a bank account for bank, a holder email or phone for a wallet, an alias for a real-time-payment method, or a tokenized card for card. A code that cannot receive funds is rejected with payment_method_not_supported_as_destination.

Codes by family

The family headings below are a documentation grouping only - the API returns the code, never the family. Within each family the codes are listed alphabetically.

Cards

Code	Method
`card`	Card

Every card scheme is charged with the single code card; see Card payments.

Card wallets

Code	Method
`apple_pay`	Apple Pay
`google_pay`	Google Pay

Bank transfers

Code	Method
`bank`	Bank Transfer
`breb`	Bre-B
`codi`	CoDi
`cvu`	Transferencia CVU
`oxxo_pay`	OXXO Pay
`spei`	SPEI

Bank debits

Code	Method
`instant_bank`	Instant Bank Payments
`pse`	PSE

Bank redirects

Code	Method
`bancontact`	Bancontact
`blik`	BLIK
`eps`	EPS
`fpx`	FPX
`ideal`	iDEAL
`interac_etransfer`	Interac e-Transfer
`khipu`	Khipu
`p24`	Przelewy24
`paynow`	PayNow
`rapid_transfer`	Rapid Transfer
`trustly`	Trustly
`twint`	TWINT
`webpay`	Webpay

Real-time payments

Code	Method
`payto`	PayTo
`pix`	Pix
`promptpay`	PromptPay
`swish`	Swish
`upi`	UPI

Wallets

Code	Method
`aeon_pay`	AEON Pay
`alipay`	Alipay
`bakong`	Bakong
`bkash`	bKash
`boost_my`	Boost
`bpi_online`	BPI Online
`cash_app_pay`	Cash App Pay
`dana`	DANA
`dbs_paylah`	DBS PayLah!
`easycard`	EasyCard
`easypaisa`	Easypaisa
`ezlink`	EZ-Link
`gcash`	GCash
`grabpay`	GrabPay
`hipay`	Hipay
`jazzcash`	JazzCash
`jkopay`	JKOPay
`kakao_pay`	Kakao Pay
`kplus`	K PLUS
`krungthai_next`	Krungthai NEXT
`lankapay`	LankaPay
`link`	Link
`linkaja`	LinkAja
`m_pesa`	M-Pesa
`mach`	Mach
`maya`	Maya
`maybank_qr`	Maybank QR
`mercadopago`	Mercado Pago
`mobilepay`	MobilePay
`momo`	MoMo
`mpay`	MPay
`mtn_momo`	MTN Mobile Money
`naver_pay`	Naver Pay
`nequi`	Nequi
`neteller`	Neteller
`orange_money`	Orange Money
`ovo`	OVO
`payco`	PAYCO
`paypal`	PayPal
`paypay`	PayPay
`pi_pay`	Pi Pay
`picpay`	PicPay
`plin`	Plin
`rabbit_line_pay`	Rabbit LINE Pay
`revolut_pay`	Revolut Pay
`rumc_hk`	RuMC
`samsung_pay`	Samsung Pay
`satispay`	Satispay
`skrill_wallet`	Skrill Wallet
`stc_pay`	STC Pay
`tng`	Touch'n Go
`todito`	Todito Cash
`tosspay`	Toss Pay
`tpaga`	TPaga
`truemoney`	TrueMoney
`venmo`	Venmo
`vnpay`	VNPAY
`wechat_pay`	WeChat Pay
`yape`	Yape
`zalopay`	ZaloPay

Buy now, pay later

Code	Method
`affirm`	Affirm
`afterpay`	Afterpay/Clearpay
`klarna`	Klarna
`meses_sin_intereses`	Meses sin intereses
`tabby`	Tabby
`tamara`	Tamara
`zip`	Zip

Vouchers and cash

Code	Method
`boleto`	Boleto
`efecty`	Efecty
`fawry`	Fawry
`konbini`	Konbini
`multibanco`	Multibanco
`oxxo`	OXXO
`pagoefectivo`	PagoEfectivo
`pagofacil`	Pago Fácil
`paynet`	PayNet
`paysafecard`	Paysafecard
`paysafecash`	Paysafecash
`rapipago`	Rapipago
`servipag`	Servipag
`tupay`	Tupay

Crypto

Code	Method
`crypto`	Crypto

You charge a fixed fiat amount and are settled in fiat; the payer picks the coin and network on the provider's hosted page. A payer who sends less or more than asked leaves the payment held for your decision - see Under- and overpayments.

Where the code appears​

Availability​

Discovering methods and required fields​

Reading required_fields​

Redirects and next actions​

Identity documents for LATAM methods​

Payments vs transfers​

Codes by family​

Cards​

Card wallets​

Bank transfers​

Bank debits​

Bank redirects​

Real-time payments​

Wallets​

Buy now, pay later​

Vouchers and cash​

Crypto​