Help Center

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 are used later.

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 for payment_method alipay , bizum , cashapp , gcash , klarna-network , mbway , mobilepay , multibanco , pix-automatico , wechatpay .

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.

Solidgate calculates the payment intent from payment_type and product_id. When both are sent and they conflict, the request is declined. A one-time payment with a recurring product is a conflict. When only product_id is sent, payment_type comes from the product type.