Create a hosted payment page payment
Creates a hosted payment page payment attempt. Redirect the customer to
next_action.redirect_url to complete the next_action.reason
customer action. The required-action URL is opaque and may later change
from the hosted page to a 3D Secure browser action. Use the latest
next_action.redirect_url from GET /v1/payments/{id}, and avoid
redirect loops when the URL is unchanged.
billing_details is required for HPP and is used to prefill the hosted
page. If the customer edits the billing details on the hosted page, the
customer-entered values become authoritative for the payment.
return_url is the merchant URL where the customer is sent after
completing or abandoning the hosted payment page. Return URL query
parameters are UX hints only; merchants must use GET /v1/payments/{id}
or webhooks as the source of truth.
Use the Idempotency-Key header to safely retry requests.
Authorizations
Use your secret API key as the Bearer token. Test mode keys start with
api_test_sk_ and live mode keys start with api_live_sk_. Both modes
use the same API host; the mode is determined by the key.
Headers
A unique key to ensure the request is processed only once. If a request with the same idempotency key and the same body has already been processed successfully, the original response is returned. Non-2xx responses are not cached, so callers may retry after errors. Keys expire after 24 hours.
For one-shot requests, such as creating a payment from a checkout button, a random UUIDv4 is fine. For requests tied to a specific business operation, such as refunding an order, a deterministic key is preferred so retries collapse correctly across processes.
255Body
Payment amount in minor units.
x >= 12500
Three-letter ISO 4217 currency code. Currently supported for card
acquiring: EUR.
EUR "EUR"
Merchant URL where the customer returns after hosted payment completion or abandonment.
"https://shop.example.com/checkout/complete"
Optional merchant-side reconciliation reference. The value must contain exactly 10 decimal digits and does not provide idempotency by itself.
1000000000 <= x <= 99999999991234567890
Merchant-provided payment description.
500"Order #5678"
Response
Hosted payment page payment accepted and a Payment object was
created. When provider submission succeeds, the payment moves
directly from PENDING to REQUIRES_ACTION with
next_action.reason and next_action.redirect_url; it does not
pass through PROCESSING before customer redirect. Use the Payment
object's status from GET /v1/payments/{id} or webhooks as the
source of truth for the final outcome.
A Payment represents one attempt to collect funds from the customer.
Merchants can use merchant_reference to associate multiple
payment attempts with the same order or checkout in their own systems.
Unique opaque identifier for a payment (pay_ prefix + random alphanumeric suffix).
^pay_[A-Za-z0-9]{24}$"pay_q7Mk2Np8Vr4Xt6Yz9Ab3Cd5E"
Payment amount in minor units.
x >= 14999
Three-letter ISO 4217 currency code. Currently supported for card
acquiring: EUR.
EUR "EUR"
Current status of a payment attempt.
PENDING-- The payment was accepted by Flowlix and is awaiting provider submission or the next lifecycle decision.REQUIRES_ACTION-- Customer action is required, such as completing 3D Secure authentication or a hosted payment page.PROCESSING-- The payment is being processed by downstream payment systems.SUCCEEDED-- The payment completed successfully.FAILED-- The payment was declined or failed permanently.CANCELED-- The payment was canceled before completion.EXPIRED-- The customer did not complete a required action before its expiry time.
PENDING, REQUIRES_ACTION, PROCESSING, SUCCEEDED, FAILED, CANCELED, EXPIRED "SUCCEEDED"
How the payment was collected. This is separate from the payment method
instrument, such as card or a future wallet.
DIRECT, HOSTED_PAYMENT_PAGE "DIRECT"
Total amount successfully refunded so far, in minor units.
x >= 00
Remaining amount that can be refunded, in minor units.
x >= 04999
Unix timestamp when the payment was created.
1719792000
Whether this payment was created using a live API key.
false
Merchant-side reconciliation reference, if provided.
1000000000 <= x <= 99999999991234567890
Merchant-provided payment description.
"Order #1234"
Masked card details, or null before card details are available.
Billing details captured for the payment, if available.
Machine-readable reason code when the payment reaches a terminal failed status.
invalid_request, not_found, processor_error, processor_unavailable, generic_decline, do_not_honor, issuer_declined, insufficient_funds, invalid_number, invalid_expiry, expired_card, invalid_amount, invalid_currency, not_permitted, cardholder_limit, card_velocity_exceeded, lost_card, stolen_card, suspect_fraud, fraud_filter, payment_canceled, three_d_secure_failed, three_d_secure_timeout, three_d_secure_not_supported, three_d_secure_error "insufficient_funds"
Human-readable explanation when the payment reaches a terminal failed status.
"The card has insufficient funds."
Refunds created for this payment, oldest first.
Timestamps for important payment status transitions.
Customer action required to continue the payment.