Skip to main content
Both payment paths use the same authentication, Payment resource, final statuses, and error format. Choose the path that matches how you collect card details.

​
Before you start

  • A Flowlix Sandbox secret key.
  • curl or another server-side HTTP client.
  • A server endpoint that can receive the customer at return_url.
  • A stable, opaque, non-PII customer or recognized-guest identifier.
  • A supported payment currency for the new Payment. Other well-formed currency codes receive 422 currency_not_supported; use a new key if you change the request.
  • Five minutes for one test payment.
Configure the shared environment variables once in Authentication, then continue below.
Both /v1 payment-create operations now require merchant_customer_id. Deploy it before the coordinated activation; there is no /v2 endpoint or compatibility window. Use the same opaque value for the same logical customer or recognized guest, for example cust_opaque_42.
Do not use an email, phone number, login, name, order/payment/attempt ID, or a fresh per-payment UUID. The value is case- and whitespace-sensitive and must be nonblank, contain 1–255 Unicode scalar values, and contain no U+0000. See Customer identity.

​
Choose your path

Hosted Payment Page Quickstart

Choose HPP when you want Flowlix to collect card details on a hosted page. Your server creates the Payment, redirects the customer, and retrieves the final result.

Direct API Quickstart

Choose Direct API only when your checkout and backend are approved to handle raw card data. Your server submits the card and handles any 3D Secure redirect.

​
What both paths finish with

Each quickstart ends by retrieving GET /v1/payments/{id} until the Payment reaches a terminal status:
  • SUCCEEDED — fulfil the order.
  • FAILED — inspect failure_code and create a new Payment for another attempt when appropriate.
  • EXPIRED — the customer did not complete the required browser action; create a new Payment if they try again.
Do not fulfil from the browser return page alone. It is a navigation signal, not proof of payment.

​
After your first payment

Refunds

Return the full or partial refundable amount and track the Refund through its parent Payment.

Payouts

Submit a card payout, retrieve it by ID, and reconcile payout lists.

Payment lifecycle

Handle every non-terminal and terminal Payment status.

Webhooks

Receive and verify Payment and Refund events on your server.

API errors

Branch safely on HTTP status, error.code, and Request-Id.