How do APM payments work?

October 16, 2026

We explain how alternative payment methods (APM) and the multiprocessor flow work in Kushki

We explain how alternative payment methods (APM) and the multiprocessor flow work in Kushki

Alternative payment methods (APM) let your customers pay without a card, using real-time payment rails. In Colombia you can now accept payments with Bre-B: the customer scans a QR code from their banking app and authorizes the payment instantly.

APM work with a multiprocessor flow: a single integration with the Kushki API, in which the processor you use in each transaction defines how you integrate and how your customer pays. Your merchant can have one or several processors enabled, and as more are enabled your integration does not change: you just query which processors you have and build the token according to each one.

The model: check your processors

Every APM integration starts with the same question: which processors does my merchant have? The answer lives in one place:

GET /transfer/v1/config (with your public credential) → processors[]

Each entry in the response tells you how to continue:

The chosen entry…	Is a processor of…	The token is built…
With `supportedFlows` (Bre-B)	APM payment flows	With `processor: { name, flowType }`, copied exactly from the response; only `amount` and `currency` remain required.
Without `supportedFlows` (ACH)	Bank redirection (traditional)	Without the `processor` object. Follow the bank transfer guide.

If your merchant has several processors, use each entry’s supportedFlows to know how to build the token with each one. If it has only one you can skip the query, but integrate it from the start: it is the product rule as more processors and flows are enabled.

The flow, end to end

The merchant calls GET /transfer/v1/config and receives processors[], with the supportedFlows of each entry.
It chooses the processor and the flow.
It requests the token with POST /transfer/v1/tokens, sending processor: { name, flowType }, and receives 201 { token }.
It initializes the transaction with POST /transfer/v1/init { token, amount } and receives the response according to the flow (Bre-B: qr in base64).
It shows the QR code to the customer, who scans it and authorizes the payment from their banking app.
Kushki reports the final status by webhook or through Get Status.

Available processors

Bre-B — real-time QR code payment

You query your processors and choose the Bre-B entry — you do not need the bank list.
You request the token with the processor object and then initialize the transaction.
Kushki responds with a QR code (base64) that you show to your customer.
Your customer scans it from their banking app and authorizes the payment in real time. The QR expires in 10 minutes and you can cancel the transaction while it has no final status.
You receive the final status by webhook or by querying it with Get Status.

The full guide is in Accept Bre-B payments.

Build the token according to the processor

Case	`processor`	Required	Notes
Bre-B QR	`{ "name": "Bre-B Credibanco Processor", "flowType": "QR" }`	`amount`, `currency`, `processor`	`bankId` does not apply; the other fields are optional.

The processor object does not allow additional properties (it returns 400) and flowType has no default value: its values are copied from the processor query, without aliases.

Conditional rules for COP

They always apply when you send these optional fields:

Condition	Rule
`userType: "1"` (legal entity)	`documentType` must be `"NIT"`.
`userType: "0"` (natural person)	`documentType` cannot be `"NIT"`.
`documentType: "PP"` (passport)	`documentNumber` alphanumeric, minimum 6 (`^[0-9a-zA-Z]{6,}$`).
Any other `documentType`	`documentNumber` digits only, minimum 6 (`^[0-9]{6,}$`).

Token ↔ processor compatibility

The token is bound to the processor it was generated with; POST /transfer/v1/init validates it:

Generated token	Merchant’s processor	Result
With Bre-B `processor`	Bre-B	Continues (the response includes `qr`).
With `processor`	Another processor	`422 E046`.
Without `processor`	Bre-B	`422 E046`.
With Bre-B `processor`	Bre-B without keys configured	`404 E049`.

If you receive E046, check the processor query and regenerate the token with the correct processor. The errors for each case are in the API errors section of the guide Accept Bre-B payments.

Integrate each processor

Accept Bre-B payments

Real-time QR code payment integration