Help Center

Create the first alternative payment order, then set how stored credentials are used later. Method support for each payment_type is in the tables below.

Init future payment

Billing logic defines who initiates a payment and whether the customer is present.

Payment type is the API value in future_usage.payment_type . The value can differ from the billing-logic label. unscheduled is a superset of Unscheduled, Recurring, and 1-click when the provider does not restrict token use. When a method supports both a native type and unscheduled , send the native type.

Description

Defines the usage of stored payment credentials.

Should be provided either future_usage or product_id.

Example

{
  "future_usage": {
    "payment_type": "recurring"
  }
}

Description

Type of the token usage scenario.

• one-time no token created, for one-off use. Maps only to One-time billing logic.
• 1-click token for future customer-initiated payments without re-entering details. Maps only to 1-click billing logic.
• recurring token for fixed scheduled merchant-initiated charges, for subscriptions. Maps only to Recurring billing logic.
• unscheduled token for unscheduled or variable merchant-initiated charges, for auto-top-up. Maps to Unscheduled, Recurring, and 1-click when the provider does not restrict token use.

Init future payment calculation

Send at least payment_type or product_id. If only product_id is sent, the intent is the product type. Compatible requests use payment_type when it is present.

These requests succeed.

These requests are declined.