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
    • Scheduled payments
      • How do Credit or Debit Card Payment Recurring Charges Work?
      • Schedule 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
    • 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
    • Transactions
      • Transactions
      • Cancel payments
  • Wire Transfers
    • Banks and transaction details for bank transfer payments
    • Receive Wire Transfers
    • Check the Status of a Transaction
    • Error Codes for Transfers
  • Cash Payments
    • How do Cash Payments Work?
    • Accept a Cash Payment
    • Authorized locations
    • Error Codes for declined cash transaction
  • Alternative payment methods (APM)
    • How do APM payments work?
    • Accept Bre-B payments
  • Money Disbursement
    • Payment Distribution
    • Recharge your balance for dispersions
    • Wire Transfer
      • How Does a Payment Distribution by Wire Transfer Work?
      • Payment Distribution to Bank Accounts
      • Disburse with Bre-B
      • Error codes for transfer dispersions
    • Cash
      • How does payment distribution in cash work?
      • Distribute Payments in Cash
      • Manage your Payment Distribution Transactions
  • 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 Payment Distribution in Cash
    • 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 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.
Looking for ACH payments?
ACH is the traditional bank transfer 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 (Bre-B)APM payment flowsWith 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#

Available processors#

Bre-B — real-time QR code payment#

1.
You query your processors and choose the Bre-B entry — you do not need the bank list.
2.
You request the token with the processor object and then initialize the transaction.
3.
Kushki responds with a QR code (base64) that you show to your customer.
4.
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.
5.
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#

CaseprocessorRequiredNotes
Bre-B QR{ "name": "Bre-B Credibanco Processor", "flowType": "QR" }amount, currency, processorbankId 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:
ConditionRule
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 documentTypedocumentNumber 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 tokenMerchant's processorResult
With Bre-B processorBre-BContinues (the response includes qr).
With processorAnother processor422 E046.
Without processorBre-B422 E046.
With Bre-B processorBre-B without keys configured404 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
Modificado en 2026-10-16 19:49:35
Anterior
Alternative payment methods (APM)
Siguiente
Accept Bre-B payments
Built with