Payment initiation and future usage configuration are the first steps in the alternative payment lifecycle. Use the flows below to create orders and define how stored credentials will be used later.
Via API Init payment APIOperation for initiating a payment using an alternative payment method performs order creation and prepares the transaction for payment, allowing the customer to proceed with the payment process.
Init future payment
Use the Host-to-host, Payment Page, Payment Link, or Payment Form flow to initiate a future payment.
| one-time | 1-click | recurring | unscheduled | |
|---|---|---|---|---|
| Alipay alipay | supported | not supported | not supported | supported |
| Bizum bizum | supported | not supported | not supported | not supported |
| Blik Recurring blik | supported | not supported | not supported | supported |
| Cash App cashapp | supported | not supported | not supported | not supported |
| MB WAY mbway | supported | supported | supported | not supported |
| Multibanco multibanco | supported | not supported | not supported | not supported |
| Pix Automático pix-automatico | not supported | not supported | supported | not supported |
| WeChat wechatpay | supported | not supported | not supported | supported |
future_usage object Use this flow to define intent for subsequent use of the customer's payment credentials, token-based future charges.
It ensures compliance with scheme rules, reduces declines on future payments, and improves success rates. future_usage object Required
Description
Defines the usage of stored payment credentials.
Should be provided either future_usage or product_id for payment_method
alipay
,
bizum
,
cashapp
,
mbway
,
multibanco
,
pix-automatico
,
wechatpay
.
Example
{
"future_usage": {
"payment_type": "recurring"
}
}
payment_type
string
Required
Description
Type of the token usage scenario.
- one-time no token created, for one-off use
- 1-click token for future CIT without re-entering details
- recurring token for fixed scheduled MIT, for subscriptions
- unscheduled token for unscheduled/variable MIT, for auto-top-up
To streamline integration for merchants using product services, the system automatically calculates the appropriate payment intent by combining payment_type and product_id.
When both are provided, the system ensures no conflict between them. In the case of a conflict, such as a
one-time
payment with a
recurring
product, the request is declined. If only the product_id is provided, the payment_type is determined based on the product type.
Future usage |
Product type by |
Validation result |
Calculated value |
|---|---|---|---|
| - | - | DECLINED | - |
| - | one-time | OK | one-time |
| - | recurring | OK | recurring |
| one-time | - | OK | one-time |
| one-time | one-time | OK | one-time |
| one-time | recurring | DECLINED | - |
| 1-click | - | OK | 1-click |
| 1-click | one-time | OK | 1-click |
| 1-click | recurring | DECLINED | - |
| recurring | - | OK | recurring |
| recurring | one-time | DECLINED | - |
| recurring | recurring | OK | recurring |
| unscheduled | - | OK | unscheduled |
| unscheduled | one-time | OK | unscheduled |
| unscheduled | recurring | OK | unscheduled |