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.
Optional billing_details are supplied by the merchant and forwarded for
the payment. The hosted card-entry page does not let shoppers edit these
billing details. The editable cardholder-name field is separate from the
billing profile.
return_url is an absolute HTTPS merchant URL with a valid hostname
or IP address, where the customer is sent after completing or abandoning
the hosted payment page. HTTP and other schemes are rejected before
Payment creation. Host validation checks syntax; no domain allowlist
or DNS lookup is applied. Return URL query
parameters are UX hints only; merchants must use
GET /v1/payments/{id} as the source of truth.
New hosted-page Payments require one of the
supported payment currencies.
A well-formed unsupported currency returns 422 currency_not_supported
without creating a Payment. Existing Payments in other currencies remain
readable.
Use the Idempotency-Key header to safely retry requests.
Authorizations
Use the secret API key for the intended merchant and mode as the Bearer
token. Sandbox keys start with api_test_sk_. Send the key only from
your server environment.
Headers
A unique key to ensure one effective operation is processed only once.
If the same key and an equivalent operation-specific effective request
identity have already completed successfully, the original response is
returned. A different identity returns 409 idempotency_key_reused.
Non-2xx responses are not cached, so callers may retry after errors. No
fixed retention period is promised by this contract.
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 the currency's minor units, using its ISO 4217
exponent. For example, 4999 is EUR 49.99 (exponent 2).
x >= 12500
Three-letter ISO 4217 currency code supplied when creating a payment or payout. Accepted case-insensitively and with surrounding whitespace, then normalized to a canonical uppercase code before the operation is created.
A value that is not three letters is rejected with 400 parameter_invalid
(param=currency); a well-formed code that Flowlix does not accept for
that operation is rejected with 422 currency_not_supported. Neither
creates a payment or payout. The available set is validated per request instead of
being enumerated here, so enabling another currency is not a breaking
contract change. For new Payment eligibility, see the
supported payment currencies;
Payout eligibility is independent.
3 - 16^\s*[A-Za-z]{3}\s*$"EUR"
Shopper IPv4 or IPv6 address observed by the merchant during checkout. Send one literal address, not a hostname, port, or comma-separated proxy chain. Flowlix validates the complete IPv4 or IPv6 literal before registering the payment; the pattern is only an initial schema-level character and length guard.
3 - 45^(((25[0-5]|2[0-4][0-9]|1[0-9]{2}|[1-9]?[0-9])\.){3}(25[0-5]|2[0-4][0-9]|1[0-9]{2}|[1-9]?[0-9])|[0-9A-Fa-f:]*:[0-9A-Fa-f:.]*)$"203.0.113.7"
Stable merchant-scoped non-PII opaque identity. Reuse it for the same logical customer or recognized guest. Do not send an email, phone number, login, name, payment ID, order ID, attempt ID, fresh per-payment UUID, or any other fresh per-payment value. Case and whitespace are significant. The value must contain 1-255 Unicode scalar values, must be nonblank, and U+0000 is forbidden.
1 - 255"cust_opaque_42"
Absolute HTTPS merchant URL with a valid hostname or IP address,
where the customer returns after hosted payment completion or
abandonment. Parsed URIs with a different scheme or no valid host
return 400 parameter_invalid with param: return_url before
Payment creation. Malformed URI text returns 400 request_body_invalid.
Host validation checks syntax, without a domain allowlist or DNS lookup.
"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
Optional merchant-supplied payer contact and billing-address details for the payment. These details are not editable on the hosted card-entry page and are separate from the cardholder name.
Merchant-provided payment description.
500"Order #5678"
Response
Hosted payment page payment accepted and a Payment object was
created. REQUIRES_ACTION includes the hosted redirect;
PENDING records an outcome that is not safe to resubmit; and
FAILED records a terminal Payment result. A newly created HPP
Payment does not return PROCESSING before the first customer
redirect. Use GET /v1/payments/{id} 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 the currency's minor units, per its ISO 4217 exponent: 4999 is EUR 49.99 but JPY 4999.
x >= 14999
Canonical uppercase three-letter ISO 4217 currency code. Responses always return the original currency the payment was created in; a provider response never replaces it.
3^[A-Z]{3}$"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.EXPIRED-- The customer did not complete a required action before its expiry time.
PENDING, REQUIRES_ACTION, PROCESSING, SUCCEEDED, FAILED, EXPIRED "SUCCEEDED"
How the payment was collected. This is separate from the payment method
instrument, such as card.
DIRECT, HOSTED_PAYMENT_PAGE "DIRECT"
Known submitted direct method or authoritative selected hosted-page method. Null means unknown, not card; the field is always present. This does not imply success. No wallet credentials or authentication payload is returned.
The apple_pay and google_pay values are Experimental: wallet support
and this guidance are still being refined and are not final. See
wallet contract availability.
Total amount successfully refunded so far, in the payment currency's minor units, per its ISO 4217 exponent.
x >= 00
Remaining amount that can be refunded, in the payment currency's minor units, per its ISO 4217 exponent. This is 0 unless status is SUCCEEDED, because no amount was captured on a payment that has not succeeded. For a SUCCEEDED payment it is the payment amount less anything already refunded or reserved for a refund in flight.
x >= 04999
Unix timestamp when the payment was created.
1719792000
Always false for a Payment created in Sandbox.
false
Merchant-side reconciliation reference, if provided.
1000000000 <= x <= 99999999991234567890
Merchant-provided payment description.
"Order #1234"
Billing details captured for the payment, if available.
Machine-readable reason code when the payment reaches a terminal failed status.
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, 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.