Skip to content
BaxPayDevelopers

Reference

Changelog

Notable changes to the public API. Everything here is additive to /v1 unless explicitly marked otherwise.

2026-11-07

Sandbox host, shorter developer paths, test invoices stay in BaxPay

  • Sandbox host: https://sandbox-api.baxpay.com/v1 serves bx_test_ keys and refuses live keys with 403. Live stays on https://api.baxpay.com/v1, which still accepts test keys for existing integrations (sandbox).
  • Paths without /developer: /v1/webhooks, /v1/events, /v1/deliveries, /v1/requests, /v1/connections, /v1/sessions and /v1/ping. The /v1/developer/… paths keep working.
  • Test invoices never leave BaxPay: no plateforme agréée deposit or status, no directory lookup at the PA, no real card payment, no SMS. Test payment links always use the simulated card flow.
2026-11-06

Developer workspace: event log, request log and sandbox data

  • Event log: every event is recorded for 30 days, even with no endpoint subscribed. GET /developer/events, /events/{id} and /deliveries, and POST /developer/deliveries/{id}/resend (webhooks). A payload's id is now the event's id, still the same on every endpoint and retry.
  • Each delivery keeps your endpoint's HTTP status, the first 2 KB of its answer and the latency.
  • Request log: every call made with an API key, for 30 days, never with bodies, headers or keys. GET /developer/requests and /requests/{id} (conventions). Every such call now returns an X-Request-Id.
  • Webhooks: PUT /developer/webhooks/{id} edits, pauses (INACTIVE) and resumes (ACTIVE, which also revives a FAILED endpoint); POST …/{id}/roll-secret replaces the signing secret.
  • Dashboard: switch a browser tab to sandbox from the profile menu and every page of that tab shows test data, while other tabs, your team and your tills stay live. Test-card and terminal buttons, a test till, and "Delete all test data" (sandbox).
  • Card charges from the dashboard (/business/acquiring/charges, /terminal-charges) refuse X-Baxpay-Mode: test. Analytics follows the mode.
2026-11-06

Docs you can run, and the fixes they found

  • Every request sample on this site now runs against the API in an automated suite, in cURL, Node and Python. New API conventions page (envelope, pagination, idempotency, rate limits).
  • Webhooks with an API key: POST/GET/DELETE /developer/webhooks and /{id}/test. events must name events that actually fire; new payment_session.expired.
  • Mode wall: a bx_test_ key can no longer read or change live records by id, and vice versa (payment links, e-invoices, clients, products, webhooks); settlement batches are per mode.
  • Fuel: voiding a pre-auth releases the hold; capture and release send their webhook and callback; holds left alone are released after 2 hours; abandoned sessions become EXPIRED.
  • Settlement: closing a day takes only that Europe/Paris day and mode, with the fees actually charged; CSV exports return CSV.
  • Products: API keys can create and update products (image optional).
  • Shopper factors (/biometric, /pin) are accepted only from the BaxPay terminal.
2026-10-30

Online shop docs

  • New section Online shop: turning a shop on, addresses and custom domains, orders, delivery options and team roles.
  • Storefront API: the public endpoints to build your own shop front end — catalog, quote, checkout and the order page.
  • Bookings: free slots, booking at checkout, the customer booking page (calendar file, cancel, reschedule).
  • Theme development: Theme studio, the baxpay-theme file, tokens, sections, custom CSS hooks, review and selling themes.
  • Payments that paid a shop order now carry metadata.shopSale (order number, order or booking); paid orders fire the existing payment_link.paid webhook with the order number as reference.
2026-07-21

Accounting page & ERP OAuth docs

  • Developers → Accounting is separate from POS Connections: Pennylane, QuickBooks, Sage OAuth, and catalog webhooks live there.
  • New docs: Accounting & ERP sync. Connections docs now cover tills / pumps only.
  • Catalog push / OAuth sync / import APIs unchanged; dashboard navigation and env setup clarified.
2026-07-16

Payment links (charge without an invoice)

  • New Payment links API (/payment-links): create a hosted charge for any amount — no invoice required. Payers pay by card or with their BaxPay account.
  • Clients promoted to a general resource: use clientId on payment links as well as e-invoices.
  • New webhook event: payment_link.paid.
  • Quickstart rewritten around payment links — runnable end-to-end with a test key.
2026-07-16

E-invoicing (France) & payment links

  • New E-invoicing API (/einvoices): EN 16931-validated drafts, Factur-X emission, the normalized lifecycle (cycle de vie) and e-reporting for the French 2026 reform.
  • New Clients API (/clients): a per-business client book — create a counterparty once, then invoice by clientId instead of retyping the buyer block. Archive/delete never rewrites issued invoices (legal snapshot).
  • Invoice payment links: hosted pay page with guest card payment and "Pay with BaxPay"; successful payment marks the invoice encaissée automatically.
  • New webhook events: einvoice.status_changed, einvoice.paid.
2026-07-14

In-store integration

  • New Session API (/integration/sessions) for retail ECR and fuel forecourt, with local-poll and cloud-callback topologies.
  • Fuel pre-authorization with partial capture, releasing the unused part of the hold.
  • Settlement close (/integration/reconciliation), with CSV and camt.053-style JSON exports.
  • Connections: self-serve bxc_ credentials, plus nexo / OPI / IFSF adapters.
2026-07-13

Biometric identification

  • Standalone 1:N fingerprint service on ISO/IEC 19794-2 templates.
  • /fingerprint/match/sca registers the inherence factor directly against an open SCA challenge.
Launch

Payments & SCA

  • PSD2-compliant payments with two-factor Strong Customer Authentication and dynamic linking.
  • Idempotency keys on all money-moving calls; signed webhooks.
  • Low-value exemption (RTS Art. 16), with cumulative and consecutive caps.

Our versioning promise

The version lives in the URL path. Within /v1 we will add fields and endpoints, but we won't remove a field, rename one, or change the meaning of an existing value — so parse leniently and ignore keys you don't recognise, and additions can never break you.

Anything genuinely breaking ships under a new prefix. We announce deprecations at least 90 days before removal.