9/16/2026 Release

This release adds Affirm to AdyenForPlatforms merchant boarding and NAICS classification codes across the merchant API and the dashboard — alongside wallet filtering with a full design-system rebuild of the Transaction Log, a consolidated Merchant Vault filter, and a set of dashboard fixes.

Jump to: New Features · Improvements · Bug Fixes


New Features

Affirm on AdyenForPlatforms boarding

Affirm can now be boarded to AdyenForPlatforms merchants. Both of the settings this takes — which payment methods board, and which Affirm price plan applies — live on the platform's AdyenForPlatforms connection, not on individual merchants. You configure them once on the connection, and every merchant boarded through it inherits them.

  • Choose which payment methods board, on the platform's AdyenForPlatforms connection. The connection carries its own list of payment methods to configure during merchant boarding, and every merchant boarded through it gets that list — there is no per-merchant selection. Existing connections keep exactly the set they board today with no action required; Affirm is opt-in and not part of that default.
  • The Affirm price plan is set on that same connection. Affirm takes one of core, standard, or signature, chosen once beside the method list and applied to every merchant boarded through the connection — it is not a per-merchant field. The price plan becomes required as soon as Affirm is selected and is rejected at save time if missing, rather than surfacing later as a boarding failure.
  • Methods board and retry independently. Each payment method tracks its own outcome, so a re-board retries only what failed and leaves everything already boarded untouched. A failure names its cause — validation, price plan pending approval, or conflict — rather than returning a raw Adyen error.
  • A partial failure raises the connection's action banner with a summary of what went wrong, and the merchant stays eligible for another attempt while boarding continues through its remaining steps.
  • Status and retry are in the dashboard. Configuration is per platform connection; boarding status is per merchant. A merchant's connection lists each method's status, distinguishing succeeded from failed and pending, with a retry action once something is outstanding — so clearing a blocked Affirm price plan and re-attempting is self-service.
  • Removing a method does not switch it off. Editing the list governs future boarding only; a payment method already boarded at Adyen stays active for that merchant. De-provisioning is not supported.

NAICS classification codes

Merchants can now carry a NAICS classification code alongside their MCC. NAICS is the classification some processors require — Jack Henry is the first — and unlike MCC it is validated against the real catalog on every write, so a retired or invented code never reaches a processor.

  • naicsClassificationCode on merchant create and update. Send a six-digit code on POST or PATCH and it is stored on the merchant record and returned everywhere mcc is returned today, including webhook payloads. The value must be a member of the current revision, NAICS 2022 — format alone is not enough, and a well-formed code outside the catalog is rejected with a 400.
  • Merchants can be scoped to a platform's allowed codes, with a default. A platform can restrict which NAICS codes its merchants may use, set a default applied to merchants that arrive without one of their own (including merchants created through connection imports), and pair suggested NAICS codes to the MCCs it already uses. Allowed-code restrictions now hold on the dashboard's merchant screens as well, where the MCC picker previously offered the full catalog regardless of the restriction.
  • Search by what the business does, not by code. The classification pickers search the official Census keyword index, so "pizza parlor" or "plumbing contractor" resolves to a code without knowing the numbering scheme.
  • An existing code outside a narrowed list still shows. If a platform tightens its allowed list after a merchant was already classified, that merchant's current code stays visible and re-selectable on its record — narrowing governs what can be picked next, not what is already set. The same holds for MCC.
  • Where it appears. The NAICS code and its title render on the merchant detail page, and it is editable from the Merchant Data tab and the onboarding business-details screen. It is not a column on the Merchant Vault list, and boarding forms do not collect NAICS yet.

Transaction Log: wallet filtering and a rebuilt page

The Transaction Log now filters by digital wallet, and the list page has moved onto the Preczn design system.

  • Filter by Apple Pay, Google Pay, or both. Wallet is a multi-select category in the filter panel, beside Status, Payment Method, Type, and Connection. Wallet and payment method compose rather than compete — an Apple Pay transaction is still a card transaction. The wallet signal was already captured on every transaction, so history filters as far back as the log reaches.
  • Wallet is a labelled column. It pairs the wallet mark with its name, and shows an em dash where a transaction used no wallet, instead of an unlabelled glyph tucked inside the Payment cell.
  • Rows read as two lines instead of a horizontal hunt. Merchant over customer, connection over plan, and timestamp over the full transaction ID each stack inside their own column; type, status, amount, payment method, and wallet stay single-value columns. Transaction IDs render in full with a copy control and are the only inline link on a row — merchant and plan navigation lives in the row menu.
  • The filter panel is the shared one used elsewhere in the dashboard, with staged selections you commit rather than filters that fire as you click. Deep links and browser back and forward keep working, the date range stays in the toolbar, and the one-year archive lookback clamp is unchanged.
  • Column-visibility toggling and the on-row imported indicator are gone. Transaction provenance moves to the transaction detail view.

Improvements

Merchant Vault

  • One Filter button instead of two. The Filter dropdown and the Labels button are now a single Filter popover with six categories: Connection (connections, connection status, whether a connection has updated, and how long ago), Labels, MCC, Action Required, Plans, and Merchant Updated. The Connection, MCC, and Plans panes are searchable. No query parameter changed name, shape, or meaning, so existing deep links and bookmarks keep working, and the trigger badge now counts categories rather than individual options.
  • The list always contains every merchant. The Show Disabled checkbox is gone; active and inactive merchants are always listed, so the list means the same thing whether or not a filter is applied.
  • Disabled merchants say so. A Disabled chip now sits beside the merchant name, alongside the existing marker down the row's left edge.

Bug Fixes

Dashboard

  • The Create New Form drawer shows each connection's real status. Every connection in the drawer's checklist displayed a green "Active" pill regardless of its actual state, so a connection sitting in Requirements or RFI looked ready. It now matches the status shown on the merchant header. Which connections can be selected for a form is unchanged.
  • Latest updated merchants: pills now sit under the right connection. The connection column headers and the row cells beneath them were generated independently, so a merchant boarded to a different set of connections could have its status pills land under headers naming other connections — readable as the wrong connection's status. Headers and rows now draw from one shared, ordered list.
  • Cosmetic fixes. The empty-state buttons on the connections and plans pages, and both buttons in the "Switch to Live mode?" confirmation, now use design-system colours in dark mode instead of legacy blue. Merchant connection status headers no longer break mid-word on narrow viewports. The bulk plan move error now reads "credentials."