A maintenance release that splits Flopay's own full backend test run into shorter stages and makes a stage that is stopped say so, with no change to checkout, payments or the public API.
Before a change to Flopay's backend is merged, its full automated test run checks the code, runs every backend unit test and builds the service. On build machines with few processors, running every backend unit test in a single step took longer than the machine lets one step run. The machine then stopped the step and reported a plain failure with no test results, even though no test had failed.
What changed
- The backend unit tests now run as four separate stages, each covering about a quarter of the tests, so each stage takes a fraction of the time the single step did.
- Each stage has its own time limit, set below the build machine's. A stage that runs too long, or that is stopped from outside, now reports that it timed out or was stopped, instead of a plain failure with no output.
- A stage that is stopped now ends together with every process it started.
- What the run checks is unchanged: the same code checks, every backend unit test and the build. The automated checks that run on every change are unchanged too.
Why it matters
- A failed pre-merge test run again points to a real problem in the change, so fixes reach merchants without being held up by failures that came from the build machine's time limit.
Developer notes
- No public API endpoint, request or response field, webhook payload, SDK export, or documented configuration changed.
- No merchant action is required. This release contains no breaking changes.
Saving a card without a purchase could end in an error for a customer who already had a saved default card, including on the return from 3D Secure authentication. The setup now completes and the card is saved.
Saving a card without a purchase (a card setup) could end in an error for a customer who already had a saved default card. The error came when the setup finished, for example on the return from 3D Secure authentication, and the new card was not saved.
What changed
- A card setup now completes for a customer who already has a saved default card.
- The default card is chosen as before: a card from a newer setup becomes the default, and a setup that started earlier but finished later is saved without replacing the newer default.
Why it matters
Customers can add another card to their account, and merchants can rely on the setup completing, whether or not a card was already saved.
Developer notes
- No request, response or webhook changes.
- This release contains no breaking changes.
A product update that sends `recurringTrialPeriodDaysFree` as `null` now succeeds and keeps the product's current trial setting, instead of failing with a server error.
Updating a product with PATCH /v1/products/{uuid} and sending recurringTrialPeriodDaysFree: null failed with a 500 server error. The request now succeeds.
What changed
- When a product update sends
recurringTrialPeriodDaysFree as null, Flopay treats the field as not sent. The product keeps its current setting for whether its trial is free, and the rest of the update is applied.
- Updates that leave the field out, or send
true or false, behave exactly as before.
Why it matters
- Integrations that send every product field on update, including empty ones as
null, can update products without a server error.
- An empty value never switches a product's trial between free and paid, so the trial stays as the merchant set it.
Developer notes
- No endpoint, request or response field, validation rule or SDK export changed.
- To change whether a product's trial is free, send
true or false. Sending null leaves the current setting in place.
- No merchant action is required. This release contains no breaking changes.
A checkout request whose session token is not a valid token is now answered with 401 Unauthorized, the same response as a wrong token, instead of a 500 server error. No integration action is needed.
A checkout request that carried a malformed X-Checkout-Session-Token, for example arbitrary text or a cut-off token, could fail with 500 Internal Server Error. It is now rejected with 401 Unauthorized before the session is looked up.
What changed
- A session token that is not a well-formed token gets
401 Unauthorized with the same response body as a wrong token.
- A valid token is checked exactly as before: the matching token is accepted, a wrong token gets
401, and an unknown session gets 404.
- A missing token still gets
401, as before.
Why it matters
- Integrations can treat a malformed token like any other rejected token, with no retries on a server error that a retry would never fix.
Developer notes
- Send
X-Checkout-Session-Token exactly as Flopay issued it. A different spelling of the same value, such as without its hyphens or wrapped in braces, is now also answered with 401. Tokens issued by Flopay are not affected.
- No endpoint, request or response field, or SDK export changed. The only status change is
500 to 401 for a malformed token.
- No merchant action is required. This release contains no breaking changes.
A card payment on a checkout session that was created with only a customer identifier now completes when the buyer types their email into the hosted card form. Previously the charge was refused after the card details were captured and the form timed out after two minutes.
A buyer whose email was collected in the hosted card form, on a session the merchant created with a customer identifier but no email, could not pay by card: the captured card was refused at the charge step and the form showed a timeout after two minutes. Pressing Pay again repeated the failure.
What changed
- The email typed into the hosted card form now identifies the buyer before the captured card is charged, so the payment completes and the buyer is linked to the merchant's customer identifier as usual.
- A later identification of the same session with a different email is still rejected once a buyer is bound, so a session cannot be re-pointed at another customer.
Why it matters
Merchants who create checkout sessions server-side with a customer identifier and collect the email in the payment form no longer lose those card payments, and buyers no longer see a timeout after entering their card details.
No integration action is required.
A maintenance release that moves several third-party libraries used to build, test and run Flopay's backend to newer patch and minor versions, with no change to checkout, payments or the public API.
Flopay's backend relies on a number of third-party libraries. This release moves several of them to newer patch and minor versions, so the backend keeps receiving their fixes.
What changed
- Several libraries used to build, test and run the backend are on newer patch and minor versions, including one update flagged by a low-severity security advisory.
- No library moved to a new major version.
Why it matters
- Keeping libraries current means the backend picks up upstream fixes, including security fixes, without waiting for a larger upgrade.
Developer notes
- No public API endpoint, request or response field, webhook payload, SDK export, or documented configuration changed.
- No merchant action is required. This release contains no breaking changes.
A maintenance release that corrects Flopay's internal developer documentation about when the backend's end-to-end tests run, with no change to checkout, payments or the public API.
Flopay's internal developer documentation and code comments said that the backend's end-to-end and browser tests ran automatically before a change was merged. In fact developers run them by hand against a local environment. The documentation now says so, so nobody relies on a check that does not run.
What changed
- Developer documentation and code comments now say that the end-to-end and browser tests run only locally, not automatically before a change is merged.
- The checks that run automatically before every merge are unchanged: code checks, every backend unit test, and a build of each backend service.
Why it matters
- The documentation now matches the checks a change actually passes before it reaches merchants.
Developer notes
- No public API endpoint, request or response field, webhook payload, SDK export, or documented configuration changed.
- No merchant action is required. This release contains no breaking changes.
The API now accepts an optional statementDescriptor on your company, collections and products, checks it when you save it and returns it in responses. Flopay does not send it to payment providers yet, so what customers see on their statements does not change.
Flopay is adding statement descriptors, the text a customer sees on their card or bank statement for a payment. With this release you can save that text through the API once for your whole company, for a collection or for a product. A saved descriptor is not sent to any payment provider yet, so payments and statements are unchanged.
What changed
- New
statementDescriptor field. PATCH /company, product create and update, and collection create and update accept an optional statementDescriptor. It holds only the part of the statement text that follows your payment provider account's own prefix, for example SUCCESSWISE, not the full statement text.
- Saving, changing and clearing. Leading and trailing spaces are trimmed and the case is kept as sent. Sending
null, "" or only spaces clears the value. Leaving the field out of an update keeps the value already saved.
- Validation. A value is refused with a
400 when it is longer than 18 characters, contains no letter, or contains any of < > \ ' " *. The error message names statementDescriptor and the rule that was broken.
- Updating your company.
PATCH /company now accepts currency, statementDescriptor or both, and a body with neither is refused with a 400. A currency-only request works exactly as before, and the endpoint is still limited to owners and admins.
- Responses. Your company, a single product and collections, including the products listed inside a collection, now return
statementDescriptor, which is null when nothing is set. The product list does not include it; read a single product to see it.
- Warnings list. Create and update responses for your company, products and collections now include
statementDescriptorWarnings. Each entry is meant to flag one of your active gateways whose prefix leaves too little room for the saved descriptor, with gatewayId, gatewayName, prefix, maxLength and preview. A warning never blocks the save. No gateway reports its prefix yet, so the list is always empty in this release.
- MCP.
Product_update, Collection_create and Collection_update show the statementDescriptor value in the preview you confirm. Company_update still changes only the reporting currency and refuses a request that includes statementDescriptor.
Why it matters
- Customers who do not recognise a charge are more likely to dispute it. Merchants selling several brands from one payment provider account can now record the statement text for each product, collection or the whole company. This is the foundation for showing that text on customers' statements.
Developer notes
- The new fields are additive and optional. Requests that do not send
statementDescriptor behave as before. If your integration rejects unknown response fields, allow statementDescriptor and statementDescriptorWarnings.
- To set the company-level value, call
PATCH /company directly; the Company_update MCP action does not accept it.
- Saving a descriptor does not change any payment request in this release.
- This release contains no breaking changes.
A maintenance release that moves the automated checks, release and delivery of Flopay's backend to Flopay's own self-hosted build service, with no change to checkout, payments or the public API.
Every change to Flopay's backend is checked before it is merged, released with a version and release notes, and then delivered to production and to the staging environment. That work now runs on Flopay's own self-hosted build service instead of a third-party one.
What changed
- The checks a change must pass before it is merged are the same: code checks, every backend test, and a build of each backend service.
- A release is still versioned and given release notes in the same way, and is delivered to production only after those checks pass on the exact released code.
- Database updates still run before any service of a release starts, and the services that process background work are still updated before the API.
- The staging environment now receives each change straight from the released code, after production.
Why it matters
- Releases and their checks no longer depend on a third-party build service, so fixes reach merchants on infrastructure Flopay runs itself.
Developer notes
- No public API endpoint, request or response field, webhook payload, SDK export, or documented configuration changed.
- No merchant action is required. This release contains no breaking changes.
An Apple Pay or Google Pay wallet saved without a purchase now keeps its card brand, last four digits and expiry, so customers can tell their saved methods apart on the hosted manage page and merchants get the same card details from the payment methods API.
A wallet a customer saved without a purchase, for example on the hosted manage page, was listed only as "Apple Pay" or "Google Pay". It is now saved with the card behind it.
What changed
- When an Apple Pay or Google Pay setup completes, the card brand, last four digits and expiry month and year of the card behind the wallet are saved with it.
- The hosted manage page lists such a wallet as, for example,
Apple Pay · Visa •••• 4242.
GET /v1/payment-methods returns brand, lastFour, expiryMonth and expiryYear for these wallets, as it already does for cards.
Why it matters
Customers with more than one saved wallet, or a wallet and a card, can tell them apart when they choose a default or remove one.
Developer notes
- No response shape changes: the fields already exist and were
null for these wallets.
- The card details are read with the setup itself, on the account the setup ran on. If they are not available, the wallet is saved and the setup completes exactly as before, without them.
- Wallets saved before this release keep empty card fields; there is no backfill.
- Bank debit and card setup are unchanged. No migration.
- This release contains no breaking changes.