Checkout

Checkout

Take payments on a Fluveo-hosted page — no front-end card code.

Status: contracted_test. Checkout Sessions are in the generated API Reference and the hosted page is available for test-mode flows. Production mode is not promoted.

Fluveo Checkout is hosted: your server creates a session, you redirect the customer to a Fluveo-hosted page, they pay there, and Fluveo redirects them back. The card fields, PCI scope, and 3-D Secure all live on Fluveo’s page — you never handle a PAN.

Coming from Stripe? There is no Fluveo.js and no Elements. Fluveo does not ship a client-side card SDK or a mountable <PaymentElement/>. Card entry happens on the Fluveo-hosted page (powered by FluveoLoader), and you integrate by redirect, not by embedding a component. If you were using Stripe Elements, this is the part of your integration that changes.

Hosted Checkout vs. direct Payment Intents

There are two ways to take a payment with Fluveo. Pick one per flow:

Hosted CheckoutDirect Payment Intents
Front-end workNone — Fluveo hosts the pageYou build and collect card data (via the vault)
PCI scopeLowest (SAQ A)Higher
Control over UIFluveo-hosted pageFull
Best forGetting live fast, low PCI burdenCustom checkout, in-app flows

The rest of this page is the hosted-Checkout golden path. For the direct API, start with the Quickstart and Payments.

Take your first payment with Checkout

Four steps take you from nothing to a completed hosted payment.

1. Create a Checkout Session on your server with the line items and where to send the customer afterward. The response includes a hosted url.

curl
$KEY=$FLUVEO_API_KEY
$curl -s -X POST https://api.fluveo.dev/v1/checkout/sessions \
>  -u "$KEY:" -H "Content-Type: application/json" \
>  -d '{
>    "mode": "payment",
>    "success_url": "https://example.com/thanks?session_id={CHECKOUT_SESSION_ID}",
>    "cancel_url":  "https://example.com/cart",
>    "line_items":  [{
>      "price_data": { "currency": "usd", "unit_amount": 4242, "product_data": { "name": "Demo Plan" } },
>      "quantity":   1
>    }]
>  }'
$# → { "id": "cs_…", "url": "https://pay.fluveo.dev/c/cs_…", "status": "open", "payment_status": "unpaid", … }

2. Redirect the customer to the session url. They complete payment on the Fluveo-hosted page — see the hosted page for what they see and how card data is collected.

3. Handle the return at your success_url. When the customer comes back, do not trust the redirect alone — re-retrieve the session server-side and check its status before fulfilling:

curl
$curl -s https://api.fluveo.dev/v1/checkout/sessions/cs_… -u "$FLUVEO_API_KEY:"
$# fulfill only when "payment_status": "paid"

4. Reconcile from your server. Merchant-public Events and WebhookEndpoints are unavailable. If the customer never returns, poll the Checkout Session from your server until it reaches a terminal state. Keep fulfillment idempotent on the PaymentIntent id. Do not treat SDK webhook helpers as proof of delivery.

That’s the whole loop. Details per step: