This product is in early access. Parameters, response structures and behaviors may change without prior notice. Do not use this version in production without first coordinating with the Kushki integrations team.
We explain how alternative payment methods (APM) and the multiprocessor flow work in KushkiAlternative 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.
Looking for bank transfer payments?
Bank transfer is the traditional integration and does not change. See Receive bank transfers.
Available only for 100% API integrations
The multiprocessor flow applies to direct API integrations: the token is requested from your backend. Kajita and Kushki.js do not support the processor object yet.
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...
WithsupportedFlows (Yape)
APM payment flows
Withprocessor: { name, flowType }, copied exactly from the response; only amount and currency remain required (plus phoneNumber in PUSH).
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.
You redirect the payer to the deepLink returned by the init; the Yape app opens on their phone and they approve the payment.
PUSH
Web / Desktop
The payer enters their mobile number at your checkout (phoneNumber, required in the token) and Yape sends a push notification to their app so they approve the purchase from Aprobar compras ("Approve purchases").
You receive the final status by webhook or by querying it with Get Status. The full guide is in Accept Yape payments.
phoneNumber is the mobile number associated with the payer's Yape account.
The processor object does not allow additional properties (it returns 400) and flowTypehas no default value: its values are copied from the processor query, without aliases.
The token is bound to the processor it was generated with; POST /transfer/v1/init validates it:
Generated token
Merchant's processor
Result
With Yape processor
Yape
Continues (the response includes ticketNumber and consentId; with DEEPLINK, also deepLink).
With processor
Another processor
422 E046.
Without processor
Yape
422 E046.
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.