1. Alternative payment methods (APM)
Kushki Docs
English
  • Español
  • English
  • Home
  • Quick Start
    • Frequently Asked Questions
    • Moving to Production
    • Policy for Important API Changes
    • Test Data
    • Error Codes
    • Latest Features
  • Payment Glossary
    • Payments Glossary
  • One-time card payments (Online)
    • Supported card brands
    • Functionalities by business model
    • Network Tokens
    • One-step Payments
      • How do Card Payments Work?
      • Accept a Card Payment
      • Direct charge (without token)
      • Accept One-Time Payments with OTP
      • OTP Authentication Error Codes
      • Error codes for single card payments
    • Two-steps Payments
      • How do one-time payments with authorization and capture work?
      • Receive payments with authorization and capture
    • Refunds
      • Returns, cancellations, and refunds
    • 3DS Authentication
      • Introduction to 3DS
      • 3DS API integration
      • 3DS integration with kushki.js library
      • 3DS API integration plus kushki.js library
      • 3DS Error Codes
    • Apple Pay Payments
      • Apple Pay Configuration
      • Apple Pay Sandbox testing
  • Recurring Card Payments (Online)
    • Functionalities by business model
    • External subscriptions to Kushki
    • Authenticate your subscriptions with 3DS
    • Accept one-click payments with 3DS
    • Error codes in recurring charges
    • Apple Pay for Subscriptions
    • Scheduled payments
      • How do Credit or Debit Card Payment Recurring Charges Work?
      • Create a recurring charge
      • Manage your Scheduled Charges
    • OneClick Payments
      • Accepting One-Click Payments
      • How does authorization and capture work in OneClick payments?
      • Receive OneClick payments with authorization and capture
  • Card-present payments
    • Accept card present payments
    • Test data
    • Webhooks for card present
    • Raw card-present API
      • Raw card-present API overview
      • Cryptographic key exchange
      • Sample script to encrypt information
      • Take Payments
      • Frequently Asked Questions
      • Error codes for card-present transactions
    • Transactions
      • Transactions
      • Cancel payments
    • Kushki One
      • First Steps
      • Autenticación y Cifrado de Requests
      • Accept payments with Kushki One
      • Amount Format
      • Async services and webhooks
      • Printing on SmartPOS terminal
      • Unified Error Catalog — Kushki ONE Connect
    • Kushki One Payment App
      • Overview
      • Process a payment
      • Split payment on the terminal
      • Refunds and PreAuth & Capture
      • Review Your Transactions
      • Terminal Setup
  • Wire Transfers
    • Shopping experiences and transaction details for bank transfer payments
    • Receive Wire Transfers
    • Check the Status of a Transaction
  • Cash Payments
    • Accept a Cash Payment
    • Authorized locations
    • Error Codes for declined cash transaction
  • Alternative payment methods (APM)
    • How do APM payments work?
    • Accept Yape payments
  • Money Disbursement
    • Wire Transfer
      • How does the disbursement through bank transfer work?
      • Payment disbursement to bank accounts
      • Error codes for transfer disbursements
    • Card
      • How does sending funds to cards work?
      • Send money to a card
      • Error Codes
  • Plugins
    • Shopify
      • Shopify
      • Plugin Operation
    • VTEX
      • VTEX Integration Guide
  • Payment Links
    • Smartlinks
  • Payment forms and buttons
    • Kajita
      • How Does it Work?
      • Payment Kajitas
    • Payment Button
      • Overview
      • Generate a payment button
  • Branch Offices Management
    • How to Onboard Submerchants via API
  • Notifications
    • Good Practices
    • Check your Webhooks
    • One-time Payments Webhooks
      • Webhook for One-Time Payments made with a card
      • Webhook for One-Time Payments by Wire Transfer
      • Webhook for One-Time Payments in Cash
    • Recurring Payments Webhooks
      • Webhook for Recurring Payments Made with Card
    • Payment Distribution Webhooks
      • Webhook for payment disbursement through wire transfer
      • Webhook for card disbursement
    • Payment button Webhooks
      • Webhooks with Payment Button
    • Smartlinks Webhooks
      • Webhooks with Smartlinks
    • Refunds Webhooks
      • Webhook for Voids and Refunds
      • Chargeback Webhooks
HomeMexico 🇲🇽Ecuador 🇪🇨Chile 🇨🇱Colombia 🇨🇴Peru 🇵🇪
HomeMexico 🇲🇽Ecuador 🇪🇨Chile 🇨🇱Colombia 🇨🇴Peru 🇵🇪
Status
Soporte / Support
English
  • Español
  • English
  1. Alternative payment methods (APM)

How do APM payments work?

🚧 Early Release — Beta
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 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.
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.

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 (Yape)APM payment flowsWith processor: { name, flowType }, copied exactly from the response; only amount and currency remain required (plus phoneNumber in PUSH).
Without supportedFlowsBank transfer (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#

Available processors#

Yape — approval in the app#

flowTypeChannelHow it works
DEEPLINKMobileYou redirect the payer to the deepLink returned by the init; the Yape app opens on their phone and they approve the payment.
PUSHWeb / DesktopThe 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.

Build the token according to the processor#

CaseprocessorRequiredNotes
Yape DEEPLINK{ "name": "Yape Processor", "flowType": "DEEPLINK" }amount, currency (PEN), processor—
Yape PUSH{ "name": "Yape Processor", "flowType": "PUSH" }amount, currency (PEN), processor, phoneNumberphoneNumber is the mobile number associated with the payer's Yape account.
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:
Generated tokenMerchant's processorResult
With Yape processorYapeContinues (the response includes ticketNumber and consentId; with DEEPLINK, also deepLink).
With processorAnother processor422 E046.
Without processorYape422 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.

Integrate each processor#

Accept Yape payments
Integration with approval in the Yape app
Modificado en 2026-10-16 19:49:45
Anterior
Alternative payment methods (APM)
Siguiente
Accept Yape payments
Built with