https://www.marqeta.com/docs/developer-guides/release-notes/rss.xml
Marqeta rolls out Card Issuing and Processing platform releases in phases.
If you don’t see a feature in your environment yet, you will after Marqeta updates your environment to the new version.
Platform release numbers, such as V.2026.8.31.0, identify the release, not the date it becomes available.
New transaction type for processing BACS credit payments
Platform release: V.2026.8.17.0Sandbox release date: September 30, 2026Production release date: September 30, 2026Marqeta now supportsBACS_CREDIT, a new transaction type for processing Bankers’ Automated Clearing System (BACS) credit payments. This transaction type is available for UK transactions only.UK banks use BACS to send credit payments in British pounds, commonly for salary payments and supplier payments. Unlike Clearing House Automated Payment System (CHAPS), BACS payments clear over three business days rather than settling the same day.New program-level control to route all account verifications to your JIT Funding gateway
Platform release: V.2026.8.17.0Sandbox release date: September 30, 2026Production release date: September 30, 2026Marqeta now supports forwarding every $0 account verification request to your JIT Funding gateway, including requests that don’t include Address Verification Service (AVS) data.Previously, Marqeta forwarded an account verification request to your JIT Funding gateway only when the request included AVS data, such as a postal code or street address. Account verification requests without AVS data, such as contactless transit taps and recurring billing checks, were approved automatically without reaching your gateway.For programs that enable this feature, your JIT Funding gateway now receives every $0 account verification request, whether or not AVS data is present, using the same webhook method (pgfs.authorization.account_verification) and payload structure already used for AVS-present requests. When AVS data isn’t present, Marqeta omits the AVS address fields from the request rather than sending empty or null values.Use this to decline an account verification yourself instead of letting Marqeta approve it automatically, such as declining a transit fare check before the cardholder taps through and the merchant force-posts the fare.This applies to both dual-message and single-message account verification requests, across Visa, Mastercard, and PULSE.This feature requires additional activation steps. To learn about activating it for your program, contact your Marqeta representative.For more information, see Gateway JIT Funding Messages.New stop_order_token field on transactions declined by a stop order
Platform release: V.2026.8.17.0Sandbox release date: September 30, 2026Production release date: September 30, 2026Marqeta now includes astop_order_token field on transactions declined because they match an active stop order. Use this field to identify which stop order caused the decline, without having to separately look up the cardholder’s active stop orders.Previously, a stop-order decline (response code 1949) identified that a stop order blocked the transaction, but not which stop order.This field is included automatically in transaction API responses (including GET /transactions), JIT Funding requests, and webhook payloads, for transactions declined with response code 1949. It’s omitted for all other transactions.No action is required — this field is additive.For more information, see Subscription Management and Transactions.Improved error handling for digital wallet token lifecycle operations
Platform release: V.2026.8.17.0Sandbox release date: September 30, 2026Production release date: September 30, 2026On activate, suspend, and terminate requests, Marqeta forwards your request to the token service provider (TSP). Previously, when the TSP returned an ambiguous error — for example, token not found or invalid data — Marqeta passed that error back to you unresolved.Marqeta now resolves these ambiguous errors before responding. If the TSP’s error is ambiguous, Marqeta checks with the TSP directly for the token’s actual state before responding.- Terminate: If you request termination and the TSP returns an error indicating the token is not found, invalid, missing data, or already terminated, Marqeta treats the token as terminated and returns success (
201) instead of an error. No action is required from you. - Activate or suspend: If you request activation or suspension and the TSP returns an error indicating the token is not found, invalid, missing data, or terminated, Marqeta returns
422004with both the Marqeta state and the TSP state. Transition the token to terminated on your side.
Marqeta only returns
422004 when it finds a real state mismatch on an activate or suspend request. A terminate request never returns 422004 — it either succeeds (201) or returns 422003.Improved validation and error handling for POST /businesstransitions
Platform release: V.2026.8.17.0Sandbox release date: September 30, 2026Production release date: September 30, 2026Marqeta fixed the following issues withPOST /businesstransitions.- Invalid reason_code accepted: Marqeta now rejects an empty string (
"") forreason_codewith error code400001, instead of storing it as a valid value. - Idempotent replay returned an unexpected error: Reusing a transition
tokenwith a different payload now returns the documented409(error code409002), instead of an unexpected500.
status or channel value. The message no longer lists the accepted values; error code 400037 is unchanged. Rely on the error_code field, not the message text, to detect this error programmatically.For more information, see Business Transitions and Errors.Fixed: Omitting active on a gateway funding source update reactivated it
Platform release: V.2026.8.17.0Sandbox release date: September 30, 2026Production release date: September 30, 2026Marqeta fixed an issue wherePUT /fundingsources/programgateway/{token} reactivated a deactivated program gateway funding source whenever an update request omitted the active field.The active field now behaves like every other field on this endpoint: omitting it leaves the funding source’s current active state unchanged. To change a funding source’s activation state, include active explicitly in your request.For more information, see Program Gateway Funding Sources.Fixed: Invalid fields or sort_by value on GET /businesstransitions/business/ returned a 500 error
Platform release: V.2026.8.17.0Sandbox release date: September 30, 2026Production release date: September 30, 2026Marqeta fixed an issue whereGET /businesstransitions/business/{business_token} returned an unexpected 500 error when a request specified a fields or sort_by value that isn’t valid for this resource.With this release, this endpoint returns the documented 400 (error code 400004) for these requests instead.Marqeta also updated the sort_by parameter’s documentation to list the exact fields it accepts.For more information, see Business Transitions.API reference: consolidated error responses for migrated endpoints
Platform release: V.2026.8.17.0Sandbox release date: September 30, 2026Production release date: September 30, 2026Action requiredMarqeta has consolidated the error responses documented in the published API reference for a set of migrated endpoints, replacing individually listed4xx and 5xx status codes with a single default error response with a typed body.This is a documentation change only — the status codes these endpoints return are unchanged. If you generate client code from the Marqeta OpenAPI spec, error handling for these endpoints now collapses from per-status branches to a single typed error model. Update your generated clients to branch on the error response body, rather than on the previously enumerated status codes.For more information, see Errors.API reference: corrected basic_auth_password length limit for program gateway funding sources
Platform release: V.2026.8.17.0Sandbox release date: September 30, 2026Production release date: September 30, 2026The API reference for creating and updating a program gateway funding source previously documented a maximum length of 100 characters forbasic_auth_password. Marqeta has corrected this to the limit the server has always enforced: 20–50 characters, plus the complexity rule already documented for the field.This is a documentation correction only. Marqeta has never accepted a basic_auth_password outside this range.For more information, see Program Gateway Funding Sources.