Payment Gateway v6.2.3

Release Date: September 3, 2026 Tags: CURRENCIES, MERCHANTS, API-KEYS, DIAGNOSTICS, BUG-FIXES

Overview

A currency-configuration release. There is no schema change and nothing to run by hand, but there is one thing to check afterwards.

Merchants were being created unable to charge in the currency they price in. Both the admin panel's currency selection and each new merchant's currency list were filled by taking the first three entries of an alphabetically ordered list. USD sorts near the end of that alphabet — on a typical install the first three are AED, AFN and ARS — so USD was left out of both. A merchant who tried to bill in USD got "Currency USD is not supported by this merchant", and no screen anywhere showed them the list they were being tested against. Merchants created before this update keep those lists; Upgrade Notes says how to inspect and correct them.

API keys now enforce the wallet types they were scoped to. That setting had never been read, so a key restricted to one wallet type quietly accepted every type its merchant accepted. Enforcing it can refuse payments that succeed today — read Upgrade Notes first if you have ever scoped a key.

Requires Core v6.7.5.

Update Instructions

pnpm updator

There is no schema change in this release — no new table, no migration and no seeder. Both halves of pnpm updator matter: the currency validation and the merchant record are server-side and need the backend restart, while the new Payment Currencies screen and the API-key form live in the browser bundle and need the frontend rebuild.

Afterwards, run the report from the backend directory. It writes nothing:

pnpm gateway:doctor

Every item below that needs a decision is something that report names for you.

Upgrade Notes

Merchants keep the currency lists they were created with

The fix corrects how new merchants are created. It does not reach back into merchants that already exist, and there is no migration that safely could — which currencies a merchant accepts is a commercial fact about that merchant, not a value with a right answer. So a merchant registered before this update still holds whatever the alphabetical list gave it, and still cannot charge in USD if USD was not in it.

pnpm gateway:doctor reports every merchant, the currencies it accepts, its default currency, and which of those the platform will actually settle.

• Fixed new merchants being created with a currency list that excluded USD.
• Run pnpm gateway:doctor from the backend directory. If it reports nothing, no merchant needs attention.
• pnpm gateway:doctor:fix repairs what it found. It is deliberately conservative: a merchant that still has at least one usable currency keeps its list exactly as it is and only has its default currency re-pointed. Only a merchant with nothing chargeable at all has its list rewritten, because there is nothing there to preserve.
• Merchants can now correct their own list on their settings page, so you can also simply leave this to them.

API keys now enforce the wallet types they were scoped to

A key's wallet-type selection was written, shown back on the settings page as an "Accepts" badge, and then never consulted by anything. A key scoped to fiat took crypto payments regardless. It now refuses them, which is what scoping it was for — but a merchant who scoped a key months ago has never seen that take effect, and a live integration may be relying on the gap.

This is the only change in the release that can refuse a payment that succeeds today.

• Changed payment creation to honour the wallet types an API key was scoped to. A key that was never scoped is unaffected, which includes every key the platform generates for a new merchant.
• Run pnpm gateway:doctor. It names any key that will now refuse a wallet type its own merchant still accepts, which is the only combination that can break.
• If it names one, either re-scope that key on the API-keys page to include the type, or point the integration at a key that already does.

Paying in crypto needs the crypto wallet types enabled

Pricing a payment in USD and letting the customer settle it from a crypto wallet is supported, and has been: the checkout prices every wallet the customer holds and verifies the rate before taking the money. But it only offers wallet types you have enabled under Gateway → Settings. With only fiat enabled, a USD-priced payment is created successfully and then presents the customer with an empty wallet list and no explanation.

Nothing in this release changes that, because which currencies you accept is your decision. It is now reported rather than left to be discovered at checkout.

• Enable your SPOT and ECO currencies under Gateway → Settings if you intend to take crypto.
• pnpm gateway:doctor reports it when no crypto currency is enabled.

Added

A Payment Currencies screen on merchant settings

A merchant had no way to see, let alone change, the currency list their payments were checked against. The list was editable through the API the whole time, but the merchant profile the settings page loads never returned it, so nothing could display it — and the admin-side merchant page needs a gateway permission that a merchant's own account does not carry. A merchant whose list was wrong had no route to fixing it that did not go through you.

• Added a Payment Currencies card to the merchant settings page, listing the currencies the platform accepts, with the merchant's own selection and default currency editable there.
• The choices offered are bounded by what the platform has enabled, so a merchant cannot save a currency that would then be refused at checkout. A currency they hold that the platform no longer settles is named rather than silently dropped.
• Currencies stay editable after a merchant is verified. Verification freezes a merchant's name and address; it was never meant to freeze the currencies they trade in.

A gateway diagnostic command

pnpm gateway:doctor       # report
pnpm gateway:doctor:fix   # repair

• Added pnpm gateway:doctor, run from the backend directory, which checks the platform's enabled currencies, every merchant's list and default, and every API key's scope against each other, and reports where they disagree. It reports by default and writes nothing.
• It never widens the platform's own currency selection and never rewrites an API key's scope. Both are decisions, and a repair should not make them on your behalf. Adding USD to the fiat selection is available as pnpm gateway:doctor:fix -- --enable-base-currency, and has to be asked for by name.

Changed

New merchants start from what the platform accepts

• Changed merchant registration to allow every currency the platform has enabled, rather than three of them. The platform's own selection is still checked on every payment, so this widens nothing that was not already permitted — it only stops a new merchant being narrower than the platform for no reason anybody chose.
• Changed a new merchant's default currency to prefer USD when USD is among its currencies. The gateway's fees and limits are all quoted in USD, and the default was previously whichever currency happened to sort first.
• Changed merchant registration to ignore a wallet type that has been enabled with no currencies in it. Such a type cannot settle anything, and counting it as usable suppressed the fallback that would otherwise have given the merchant a working one.

An API key's currency selection keeps meaning what it said

Switching a wallet type on for a key used to copy the platform's entire currency list for that type into the key, freezing it to that day's currencies. Keys created that way carry lists like FIAT: AED, AFN, USD — the old alphabetical selection, not a choice anyone made.

• Changed the API-key form to record "every currency of this type" as exactly that, so it goes on meaning all of them after you enable a new currency. Selecting Select All does the same.
• The currency half of a key's scope is not enforced, and deliberately so. Because the stored list is a snapshot rather than a decision, enforcing it would freeze every existing key to the currencies its merchant happened to offer on the day it was made, and refuse anything enabled afterwards — with a message naming a restriction the merchant never chose. The wallet type is enforced because switching one off deletes it, which is an act. The currency list can follow once keys carry choices instead of snapshots; pnpm gateway:doctor marks the ones that still hold a snapshot.

Fixed

Merchants were created unable to charge in USD

The currency lists offered to a new merchant come from the platform's enabled currencies, and that list is built in alphabetical order. Registration took the first three of it. Since USD sorts near the end of the alphabet, it was never among them unless fewer than three currencies were active at all — on a typical install the three are AED, AFN and ARS. A merchant was created accepting those and not USD, with AED as its default currency because that sorted first too. Billing in USD then failed with "Currency USD is not supported by this merchant" — on a platform whose gateway settings, fees and limits are all denominated in USD.

The admin panel produced the same list from the same ordering. Opening the gateway settings page while nothing had been configured pre-selected those first three currencies as the platform's fiat selection, and saving the page committed them.

• Fixed merchant registration and the admin gateway settings panel both selecting currencies by alphabetical position. The panel now pre-selects USD, and pre-selects nothing at all when USD is not an active currency rather than proposing a set that cannot take a payment.

A merchant's default currency could be one it could not charge in

Nothing checked a merchant's default currency against its own list of accepted currencies. The default is what the checkout preselects, so a merchant could save a default they were not permitted to bill in, and the first payment that relied on it failed.

• Fixed the default currency being saved without checking it against the merchant's accepted currencies. Narrowing the list no longer strands the default either — it moves to a currency that still works instead of rejecting the edit.

A merchant's currency list could be emptied

The merchant update route validated the accepted-currency list only when it found one, and an empty list is not something JavaScript finds. An empty list therefore passed every check and was saved, leaving a merchant that could not bill in anything at all — every payment refused, and no screen to put a currency back. The new settings screen made this reachable by mis-click rather than only by a direct API call, so it is now refused on both sides.

• Fixed an empty currency list being accepted. Currency codes are also stored in upper case now, matching how they are compared when a payment arrives; a lower-case entry could never have matched one.