What are Alternative Payments?
Alternative Payment Methods (APMs) are every way a customer can pay you that isn't a credit or debit card. In Guatemala they include digital wallets like Zigi or Akisi, interbank QR codes such as Banco Industrial or QuickPay QR, hosted bank buttons like BAM PaymentButton, and cash references payable at convenience stores like Pronet.
In short: anywhere you'd normally accept "transfer me" or "I'll pay it through my bank app," Migo turns that into a programmatic flow.
Why they matter
LATAM has a high share of unbanked or under-banked customers, and even banked ones often prefer their wallet/QR app over typing a card. Offering APMs alongside cards typically lifts conversion noticeably — especially for first-time buyers and lower-ticket purchases.
You don't need to integrate each rail separately. Migo exposes one set of endpoints that route to dozens of wallets, banks, and cash networks; the merchant only chooses which ones to enable per country.
How it works
Alternative payments are an asynchronous checkout: you create a transaction, the customer pays in an external rail, and Migo confirms the result before you treat the order as paid. See How it works for the end-to-end lifecycle and diagram.
How APMs differ from card payments
| Aspect | Card payments | Alternative payments |
|---|---|---|
| Authentication | 3DS / CVV / token in your checkout | Customer's banking app, wallet, or QR scanner |
| Authorization | Synchronous — you get APPROVED in the response | Asynchronous — confirmed later by a processor webhook |
| Settlement | Captured at authorization | Settled once the customer authorizes outside your app |
| Required data | A card token | Method-specific payload (phone, bank id, document, voucher) |
| Failure modes | Network, 3DS challenge, decline | Customer abandons, QR expires, bank rejects push |
The four endpoints
Every APM integration uses only four endpoints — the same shape regardless of which method the customer picks:
| Endpoint | What it does |
|---|---|
POST /api/v1/integrations/transactions | Creates the transaction and returns the methods available for that merchant. |
POST /api/v1/integrations/transactions/{id}/payment-intents | (Optional) Fetches dynamic metadata for the methods that need it. Most Guatemala rails don't require it; in sandbox, fri returns a user fixture you can use to simulate an authorization. |
POST /api/v1/integrations/transactions/{id}/payments | Submits the chosen method and any user-collected data. Returns the rail-specific payload to render. |
POST /api/v1/integrations/transactions/{id}/dismiss | Cancels an unpaid or expired transaction so the merchant can recover its UI. |
All calls require Authorization: Bearer <token> — see Authentication.
Where to go next
- See every method available with country, type, and response shape in Available payment methods.
- Walk through a real integration in Create transaction.
- Understand the unified request body in Process payment.
- Browse the live API spec under
Alternative Payments.