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 digital wallets. In Peru you can now accept payments with Yape: the customer approves the payment directly in their Yape app, by direct redirection to the app (DEEPLINK, from mobile) or through a push notification to the payer’s mobile number (PUSH, from web or desktop).

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:

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

1. The merchant calls GET /transfer/v1/config and receives processors[], with the supportedFlows of each entry.
2. It chooses the processor and the flow (DEEPLINK or PUSH).
3. It requests the token with POST /transfer/v1/tokens, sending processor: { name, flowType } (and phoneNumber in PUSH), and receives 201 { token }.
4. It initializes the transaction with POST /transfer/v1/init { token, amount }. With DEEPLINK it receives deepLink, ticketNumber and consentId: redirect the payer to the Yape app. With PUSH it receives ticketNumber and consentId: the payer gets the push notification in their Yape app.
5. The payer approves the payment in the Yape app.
6. Kushki reports the final status by webhook or through Get Status.

Available processors

Yape — approval in the app

You receive the final status by webhook or by querying it with Get Status. The full guide is in Accept Yape payments.

Build the token according to the processor

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.

Token ↔ processor compatibility

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

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

Integrate each processor