Skip to main content
​
WorkflowsDashboard
Every workflow run is now recorded. Open a payment and you can go straight to the run that handled it and see how it was routed.

​
Workflow Runs

The new Runs tab under Workflows lists runs with their workflow, version, trigger, start time and status, and can be filtered by workflow, status and date range. A run is completed when the workflow reached its end, including when the payment was declined, failed or blocked along the way; running or waiting while it is still executing or sitting on a delay; and failed only when a step could not execute at all.Open a run and you get its execution path: every node the workflow evaluated or executed, in order, starting from the trigger, each with its type, status and timestamp. Conditions are explained rather than just marked — every route is listed with the one the payment took marked as matched, and inside a route each field shows its operator, the expected value and the actual value taken from the payment. Action steps carry their own evidence: an authorize step names the processor it used and, on a refusal, the decline and advice codes that came back.You do not have to search the runs list to investigate one payment. Open the payment, scroll to its Workflow Runs section, and click the run id: the run that handled that exact payment opens, with its execution path and every step’s evidence.Run history is kept for three months. See Workflow Runs for the full guide.
​
PaymentsSearch
Cash App payments now carry the customer’s cashtag, and you can search payments by it.

​
Cash App cashtag on payments

When a Cash App payment settles, PayNext captures the customer’s cashtag and shows it as the customer name on the payment. Use the new processor_customer_name: prefix in the payments search to find payments by cashtag or by Venmo username — matching is case-insensitive and works on partial values. The cashtag is available for payments settled after this release; earlier payments gain it on their next renewal.
​
PaymentsSubscriptionsDashboardAPIWebhooks
Declined recurring card payments now get a second chance the moment the funds are likely there — and you can see exactly what came of it.

​
Funds-available retries on declined recurring payments

Mastercard Payment Alerts is a card network program that keeps watching a card after an insufficient-funds decline and tells PayNext once funds are likely available again. PayNext now acts on that signal.

​
How it works

  1. A recurring Mastercard card payment is declined for insufficient funds.
  2. The card network keeps watching that card and sends PayNext a funds-available signal — directly, not through your processor.
  3. PayNext checks the subscription and either charges the card right then, or skips the signal and records why.
Signals come from Mastercard only, so coverage is limited to Mastercard cards. They are enabled per merchant account and need no integration work: contact your PayNext representative to turn them on. For the full behavior, the field reference, and the skip reasons, see Funds-Available Retries.

​
What the retry does and doesn’t do

  • The retry replaces the next scheduled dunning attempt rather than adding one, so a subscription is not charged more often than your dunning settings allow.
  • At most two signal-driven retries per dunning cycle, and no more than one every 4 hours per subscription.
  • A subscription already cancelled for exhausted dunning attempts can be revived by a single retry on the same card; if it succeeds, the subscription resumes.
  • Never charged twice: a signal for an already-recovered payment, or one that arrives while a retry is still running, is recorded and skipped.

​
See it on the payment

The payment timeline shows when a signal arrived and what was decided, and the retry payment names the declined payment it came from.Three new filters on the Payments page, under More filters → Mastercard Payment Alerts:
  • Payment Alert Received — payments a funds-available signal arrived for.
  • POP Retry Payment — payments created by such a signal.
  • POP Outcome — what the signal led to: retried, subscription revived and retried, or skipped with the reason (already recovered, retry in flight, cooldown, cap reached, ineligible subscription, duplicate signal).

​
API and webhooks

payment_details on the payment object now carries mastercard_pop_notification_id and mastercard_pop_outcome on the declined payment, and mastercard_pop_retry_of_payment_id and mastercard_pop_retry_notification_id on the retry payment. The same fields ship in payment webhook payloads, and a payment.updated event is sent when a signal is recorded against a payment. See Read the outcome on a payment.Recovered payments are ordinary payments: they create and settle through the usual events, so existing reconciliation keeps working unchanged.
​
SDKCheckoutFraud Prevention
Card payments through the PayNext SDK are now protected by an automated bot-detection challenge on the card entry form.

​
Bot protection on the card entry form

  • Applies to card payments where the shopper types their card details.
  • Most shoppers see nothing — a visible challenge appears only for visitors the check considers suspicious.
This protects checkout against automated card testing and card-enumeration attacks.
​
DashboardPaymentsFilters
Filter payments by plan, and a set of dashboard control fixes.

​
Plan filters on Payments

The Payments page gets two new filters — Plan Name and Plan ID — both in the More filters section. Both are searchable dropdowns: the options are the plans that actually have payments in your organization, searched as you type. Plan ID takes a plan’s public identifier. Options and matching come from your plan catalog.

​
Dashboard control fixes

Disabled and loading buttons no longer react to clicks, the date picker closes on selection and keeps it when reopened, and BIN fields accept digits only — pasting a list splits it into chips.
​
DashboardCustomersFilters
Find customers by the state of their saved payment methods — five new lifecycle filters on the Customers page.

​
Payment method lifecycle filters

The filters live in a Payment Method Lifecycle group under More filters.Payment method status filters by the saved method’s lifecycle status — active, expired, replaced, closed, invalid, or revoked. Network token status filters by the state of the card’s network token, which can stay active and chargeable while the card itself is expired, and Tokenized matches customers whose saved card has a network token at all.Card updater enrolled matches cards enrolled in the Card Account Updater service. FPAN out of sync finds cards whose number on file (the FPAN) is older than the card the network currently reports — for example, after a reissue the stored copy hasn’t caught up yet.
​
PaymentsSubscriptionsWebhooksAPI
Saved cards now stay current on their own. When a card is reissued, re-expires, or has its network token refreshed by the card network, PayNext updates the stored payment method in place, keeps charging recurring payments through the network token, and reports the change with a new webhook.

​
Saved payment methods keep a stable ID

A saved payment method keeps the same pm_ ID for its whole life. A card reissue updates that payment method instead of creating a new one, so customer records and subscriptions survive a reissue untouched.If you cache card details such as last4, the expiry, or the brand against a payment method ID, subscribe to the new webhook below and refresh your copy when it fires. Nothing else tells you the card behind the ID changed.

​
Payment method status

Every payment method now returns a status: active, expired, replaced, closed, invalid, or revoked. Cards also return details.network_token.status and details.network_token.last_synced_at, plus card_updater showing whether the card is enrolled in the Card Account Updater service.A card whose status is expired can still be chargeable while its network token is active — read the two together, not the card status alone. See Payment Methods.On a customer these values are current. On a payment, the network token status and sync time are frozen as they were at the moment of that charge, so a settled payment always shows what it was actually charged with.

​
New webhook: customer.payment_method.updated

This event fires once for each applied change to a stored payment method — a status change, a card reissue, refreshed card details, or a removed network token. It carries the full customer object, so you can refresh your records in one step. Duplicate and out-of-order notifications from the card network don’t produce an event.

​
Recurring billing reacts to card updates

A past-due subscription is charged immediately when its payment method becomes chargeable again, instead of waiting for the next scheduled retry.When neither the card nor its network token is usable — or the customer revoked a mandate in Cash App, Pix, PayPal Wallet, or Venmo — PayNext stops attempting charges instead of sending a run of guaranteed declines. The aborted attempt is recorded as INCOMPLETE with decline_code payment_method_disabled and advice_code do_not_try_again: collect a new payment method, because retrying won’t help.The subscription stays past due while it waits for a recovery — 30 days for a card, 14 days for Cash App, Pix, PayPal Wallet, and Venmo — and is cancelled only if nothing recovers it, with cancellation_details.reason set to dead_instrument. See Recover Subscriptions.
​
DashboardPaymentsCustomersFilters
The Dashboard is reorganized into a smaller set of tabs, and filters on Payments, Customers, and the Dashboard now sit inline above the data instead of in a drawer.

​
Dashboard tabs

  • Overview — the headline view, with Authorized, Settled, Unsettled, Auth. rate, High risk, Created, Tax, and 3DS cards.
  • Risk — a new tab covering Early fraud, Ethoca alerts, Visa RDR ratio, Visa CE 3.0 prevented disputes, Order Insights lookups, and Mastercard Consumer Clarity lookups.
  • Billing — subscription health: Active subscriptions, Active subscriptions growth, Average revenue per subscription, Dunning recovery rate, Trial activation rate, Created | Cancelled subscriptions, and Cohort retention.
  • Custom — your own selection of cards.
  • Explore — an early version of ad-hoc analysis: pick payments or customers, choose a grouping and a metric, and switch between a table and a chart.
The separate Tax, Declines, BIN Analysis, 3DS, and Payments tabs are gone. Their cards now live on Overview and Billing. Charts also support zoom, so you can narrow in on a period without changing the date filter.

​
Inline filters

Filters on Payments, Customers, and the Dashboard now appear as pills above the data. Add, edit, or remove a filter without opening a drawer, and see everything currently applied at a glance. Reset filters is now Clear filters.
  • Amount filters with Equal, Between, Greater than, and Less than, with currency selected separately.
  • Payments and Customers default to the last 180 days when no date range is set, up from 7 days.

​
Reading the Risk tab

Disputes and fraud alerts arrive weeks after the payment they relate to, and the Risk tab attributes each one to the payment date. The most recent days in a Risk series are still filling in and read lower than they will settle at.
​
WebhooksAPIDevelopers
Webhooks now support a granular v2 event taxonomy — instead of one payment.updated, refund.updated, or subscription.updated firing on every change, each specific transition gets its own event, so you always know exactly what happened without inspecting the payload.

​
New payment, refund, and subscription events

Payments now emit one event per status: payment_v2.authorized, .settling, .settled, .declined, .failed, .cancelled, and .blocked each fire for exactly that status, and payment_v2.incomplete covers a payment waiting on 3DS or another customer action. Anything that changes without moving the status — a new fraud-alert signal, an updated ARN — arrives as payment_v2.updated.Subscriptions follow the same model: subscription_v2.activated fires for a trial converting to paid or a cancelled subscription coming back to life, subscription_v2.renewed covers a regular billing cycle or a recovered past-due payment, subscription_v2.past_due fires on each dunning retry with an attempt count, and subscription_v2.cancelled fires only once the subscription actually ends.Refunds move under the payment they belong to as payment_v2.refund.created, .settling, .settled, .declined, and .failed, since a refund is always tied to one payment.Subscribe to only what you need — a dunning integration can listen for subscription_v2.past_due alone, and a revenue dashboard can listen for payment_v2.settled alone. v1 events continue unchanged for a 90-day overlap window, giving you time to migrate; after that, v1 event types are archived and stop firing. New endpoints default to v2.

​
Webhook event IDs are now deterministic

A retried delivery of a v2 event now keeps the same event.id, so your deduplication logic can rely on it. v1 events keep their existing behavior — a fresh ID on every delivery — for the same 90-day window, until v1 is archived.
​
PaymentsWorkflowsDashboardFilters
Payments filter options reflect your organization’s data, workflow connections are easier to draw, plan names are validated for uniqueness, and refund charts bucket by refund date.

​
Payments filters

  • Dynamic filter options — option lists in the Payments filters now show only values that occur in your organization’s payments, instead of a fixed catalog.

​
Workflow builder

  • Easier connections — drop a connection anywhere on a target node or a condition branch card to connect to it, instead of aiming for the small connector dot. A highlight ring previews the target before you release.

​
Plans

  • Unique plan names — creating a plan or renaming one to a name already used in your organization is rejected, case-insensitively and including archived plans, so two plans can no longer share a name.

​
Dashboard

  • Refund charts bucket by refund date — the Refunded Rate and Unsettled Refunds charts now attribute each refund to the date the refund was created, not the date of the original payment. Net Settled Volume continues to bucket by payment date.
​
PaymentsFraud PreventionIntegrations
This release corrects a Worldpay decline reason, adds phone number support for Apple Pay and Google Pay, and lets you pass FraudSight device session data through metadata mapping.

​
Payments

  • Corrected decline reason for Worldpay — a Worldpay decline for insufficient funds now returns insufficient_funds instead of the previous withdrawal_limit_exceeded, matching how the same decline is reported for other processors.

​
Integrations

  • Apple Pay and Google Pay now send the shopper’s phone number to Worldpay — when a customer provides a phone number through the Apple Pay or Google Pay wallet sheet, PayNext now includes it in the billing address sent to Worldpay. This only applies when a billing address is already being sent.

​
Fraud Prevention

  • FraudSight device session passthrough for Worldpay — you can now map a device data collection session ID from your checkout page to Worldpay’s FraudSight risk engine using Metadata Mapping. Requires FraudSight to be enabled on your Worldpay merchant account.
​
DashboardPaymentsCheckoutWorkflowsFraud Prevention
Corrected totals and error messages in Tax analytics, working Visa CE and RDR status filters on Payments, order-independent amount validation in Checkout Preview, and a workflow builder tooltip fix.

​
Tax analytics

  • Failed submission totals are complete — the headline count and trend on Tax Failed Submissions by Error Message now cover every failed submission in the selected range, not only the error messages preselected in the category filter. The total matches Tax Failed Submissions by Error Code.
  • Readable error messages — when a tax provider returns an unstructured response, the chart shows a clean message instead of the raw response body. Messages already in a structured shape are unchanged.

​
Payments filters

The Visa Compelling Evidence Status and RDR Status filters on the Payments page now return matching payments. Both previously returned an empty result for every selection.

​
Checkout Preview

The Amount field for one-off plans validates in any input order. Entering an amount before choosing a currency no longer skips validation — the currency-independent rules apply right away, and decimal-precision rules re-run when you select or change the currency.

​
Workflow builder

Validation error tooltips no longer render through open overlays. Hovering a node or edge with an error while the Add Node menu or the validation errors panel is open no longer slices through them.
​
WorkflowsWebhooks
This release adds an in-canvas panel to locate invalid nodes on a workflow and fixes visibility and tooltip issues in the webhooks portal.

​
Workflow builder

  • Invalid Nodes panel — when a workflow fails validation on Save or Publish, a new panel lists every invalid node, grouped into Errors and Warnings. Click a node in the list to center it on the canvas — useful on large workflows where flagged nodes are hard to spot by eye. The panel updates live as you fix issues and disappears once none remain.

​
Webhooks portal

  • Add Endpoint button visibility in dark mode — the Add Endpoint button on Developers → Webhooks is now clearly visible when dark theme is turned on.
  • Tooltip fixes — event-subscription hint tooltips now appear next to the icon you’re hovering instead of detached near the top of the form, and message-attempt tooltips in the Cancelled tab no longer collapse into an unreadable vertical strip.
​
WorkflowsDashboardCheckoutWebhooks
Dashboard improvements across the workflow builder, integration editing, and Checkout Preview — plus clearer amount validation and a dark-mode fix for the webhooks portal.

​
Workflow builder

  • Auto-zoom toggle on duplication — a new control in the canvas toolbar turns off the camera auto-zoom that moves the view to a newly added or duplicated node. Turn it off to duplicate several nodes from the overview without the view jumping each time; the default behavior is unchanged when it’s on.
  • Duplicated nodes are highlighted — a just-copied or duplicated node is highlighted so it’s easy to spot on a dense canvas, even when it lands over existing nodes.
  • Long field values wrap in tooltips — hover tooltips for long unbroken values (on Set metadata, Split route Save-to config, and Authorize payment nodes) now wrap within the tooltip instead of overflowing past the node card.

​
Integration editing

Editing a processor connection now keeps your changes as you move between steps. In the Edit connection modal, a Credentials-step field you change (such as Name) is retained when you move to the next step and back — previously it reverted to the saved value.

​
Checkout Preview amount validation

The Amount field for one-off plans now validates more consistently, rejecting invalid input with clear, accurate error messages. Oversized amounts sent to the checkout session API also return a clean, readable validation error instead of a raw internal validator message.

​
Webhooks portal in dark mode

On Developers → Webhooks, the primary Create / Save button in the endpoint form is now visible in dark mode — previously it rendered as a blank white box with no readable label.
​
WorkflowsSubscriptionsDashboardCheckoutSDK
Workflow builder improvements — a new Subscription status condition, processor validation at publish time, clearer condition blocks, and fixes to duplicating and editing nodes — plus a Web SDK release to restrict accepted card networks per payment method.

​
Subscription status condition

  • New workflow condition Subscription status matches the current subscription’s status — Trial, Active, or Past due — with one of / not one of operators.
  • Available in payment (Payment Pending) workflows, on MIT branches such as subscription renewals, and evaluated only when the payment has a subscription.

​
Processor required on CIT / MIT branches

Publishing or saving a workflow is now blocked when an Authorize node on a Transaction Type = CIT or MIT branch has no processor selected:
  • CIT branches — a processor must be selected. Error: “Select a processor before publishing”.
  • MIT branches — select a processor, or enable Use last successful processor. Error: “Select a processor, or enable ‘Use last successful processor’”.
  • Payment methods whose processor isn’t manually selectable — PayPal, Pix Automático, Venmo, Cash App, Amazon Pay — are exempt.
  • New Authorize nodes now default Use last successful processor to off.

​
Clearer condition blocks

  • Condition blocks on the canvas now show the comparison operator, so two conditions on the same field are distinguishable (e.g. Card Network = Visa vs Card Network != Visa) without opening the block.
  • Operator / match-type icons are now unified across Workflow conditions, Checkout routing, and Payments / Customers / Dashboard filters — one icon per operator, and no icon reused for two meanings.
  • Condition tooltips appear on hover in workflow View mode.

​
Builder editing fixes

  • Duplicating a Condition node now keeps the condition logic in every branch.
  • Cancelling a Split-node route deletion no longer commits the deletion; a workflow can no longer be saved or published with a route total that isn’t exactly 100%.

​
Web SDK 1.2.0 — restrict card networks per payment method

PayNextCheckout.mount(...) accepts a new optional acceptedCardNetworks prop — a map keyed by PaymentMethod (CARD, APPLEPAY, GPAY) with a list of CardType per method.
  • A non-empty list overrides the dashboard configuration for that method — it can narrow or widen the accepted set — bounded to what the method technically supports.
  • The card form supports Visa, Mastercard, Discover, and JCB. Apple Pay and Google Pay additionally support American Express (CardType.AmericanExpress), which is now expressible via this prop.
  • An empty array, a missing key, or a list of only unsupported networks falls back to the dashboard default — a method is never left with zero networks and its button is never hidden.
  • Read once at mount; not part of the runtime checkout.update(...) surface.
Requires @paynext/sdk 1.2.0 or later.
​
PaymentsStripeWebhooks
PayNext now captures the Acquirer Reference Number (ARN) for settled Stripe card charges.

​
Stripe ARN capture

PayNext now stores the Acquirer Reference Number (ARN) for settled Stripe card charges and exposes it as arn on the payment — delivered on the payment.updated webhook, the same way ARN is already available for other processors.
  • The ARN is sourced from Stripe’s Payment Records API via the payment_attempt_record_entry.capture_settled webhook, and is populated once the charge settles.
  • Stripe connections should subscribe to payment_attempt_record_entry.capture_settled and have the Payment Records API beta enabled — see Stripe.
​
DashboardPayments
New Payments filters — cascading, CIT processor, descriptor source, and a Failed refund status option.

​
Cascading filters

Payments can now be filtered by cascading behavior:
  • Cascading used — whether a cascade occurred on the payment (yes/no).
  • First processor in cascading / First MID in cascading — the processor and MID of the first attempt that resulted in a cascade.
  • Cascade processor used / Cascade MID used — match payments where a given processor or MID was used in any cascade attempt, not only the final one.
  • Final processor in cascading / Final MID in cascading — the processor and MID the payment completed on.
Processor and MID options populate dynamically from your organization’s payment data.

​
CIT Processor filter

Filter payments by the processor that handled the customer-initiated transaction. With cascading, a single payment can involve multiple processors — this filter isolates payments by the CIT processor specifically. Options are dynamic per organization, with one of / not one of operators.

​
Descriptor source filter

Payments now record where their statement descriptor came from, and a new Descriptor source filter lets you segment by it:
  • Custom — sent in the payment request (overrides the default).
  • Default — the integration’s default descriptor value.
  • Processor — returned by the processor in the authorization response.
The source is resolved by precedence: processor response, then custom value, then integration default. Operators: one of / not one of. The source is recorded for payments created from this release onward — earlier payments are not matched by this filter.

​
Failed option in Refund Status filter

The Refund Status filter now includes Failed alongside Pending, Settling, Settled, and Declined — so payments whose refund failed can be segmented directly. Works with the same operators as the other options, combines with them in multi-select, and appears consistently on the Payments page and the Dashboard filters.
​
SubscriptionsPaymentsFraud PreventionWebhooks
Subscription cancellations and refunds now carry a server-attested reason — including automatic fraud_prevention attribution from Early Fraud Warnings (Stripe & Unlimit).

​
Early Fraud Warnings

PayNext now ingests issuer Early Fraud Warnings from Stripe (Radar) and Unlimit (Fraud Reports), records them on the payment as fraud_prevention.early_fraud_warning, and cancels the customer’s affected subscriptions immediately — attributed fraud_prevention with the reported payment as trigger_payment_id. See Early Fraud Warnings.

​
Subscription cancellation details

Every subscription now exposes why and when it was cancelled, on both the API and the subscription.updated / subscription.cancelled webhooks:
  • cancellation_details — { reason, trigger_payment_id }. reason is server-owned: merchant_initiated, past_due_max_attempts_reached, workflow_action, or fraud_prevention. trigger_payment_id points at the payment that caused a system cancellation (null for merchant cancels).
  • cancelled_at — when the subscription became cancelled; null otherwise, and cleared on reactivation.
  • The cancel request is unchanged ({ "type": ... }) — the reason can’t be set by the caller, and a reason-like field is rejected with 400.
See Subscriptions → Cancellation details.

​
Payment refund reason

Refunded payments now carry refund_reason (merchant_initiated or fraud_prevention), set once a refund executes and delivered on the payment.updated webhook.
​
SDKCheckoutDevelopers
SDK 1.1.0 adds checkout.update(config) to change config fields after mount without re-mounting.

​
Update configuration at runtime

After mount, call checkout.update(config) to change selected fields in place — the checkout re-renders only what changed and preserves form state (entered card data, open forms). No more unmount() + mount() for a lightweight change like switching language or theme.Updatable without re-mount:
  • locale — re-translates the UI in place.
  • translate — applies translation overrides in place.
  • theme — switches light / dark / system.
  • paymentsEnabled — same gate as setPaymentsEnabled; both now share one channel, so checkout.update({ paymentsEnabled }) and checkout.setPaymentsEnabled(enabled) are equivalent.
clientToken, environment, and apiVersion can’t be updated at runtime — they initialize the API client, so changing them still requires a fresh mount. TypeScript blocks them in update(); a plain-JavaScript call logs a console warning and is ignored (it never throws).See Update Configuration at Runtime.

​
Pix form now follows the checkout theme

The Pix form’s payment fields — email, CPF/CNPJ, name, and the QR code step — now match the checkout’s light/dark theme instead of always rendering with a fixed default look. Changing the theme at runtime (checkout.update({ theme })) re-themes an already-open Pix form immediately, with no need to close and reopen it.

​
New styles.PixForm customization

A new PixForm field on StylesConfig lets you override individual colors and the border radius of the Pix form — colorPrimary, colorBackground, colorText, colorDanger, colorTextPlaceholder, borderRadius — on top of whichever theme is active. Fields you don’t set keep the theme default.Applies to both recurring Pix Automático and one-time Pix. Available from SDK version 1.1.0. See Pix Form Theming and PixForm.
​
Fraud PreventionMastercard
Mastercard First Party Trust support on Consumer Clarity — disputed charges claiming fraud can now be assessed and deflected using your transaction receipts.

​
Fraud Prevention — Mastercard First Party Trust

Mastercard’s First Party Trust service is now supported on the Consumer Clarity integration. When a cardholder disputes a charge claiming fraud, Mastercard looks up the disputed transaction plus two of the cardholder’s older undisputed transactions and compares identity fields across the three receipts — enough matches confirm the disputer is the genuine customer, and the dispute is assessed as first-party fraud.
  • New FIRST_PARTY_TRUST channel value on fraud_prevention.mastercard_consumer_clarity.type — each of the three lookups is recorded on its payment and delivered on the payment.updated webhook, like every other Consumer Clarity channel.
  • Richer receipts for FPT matching. Receipts now additionally carry a deterministic per-customer device fingerprint, account phone, account creation date, billing name, and digital-delivery details — raising the chance the three lookups find matching fields.
  • No integration work required — the receipt is built from data you already provide. See Mastercard Consumer Clarity.
​
Fraud PreventionMastercard
Mastercard First Party Trust support on Consumer Clarity — disputed charges claiming fraud can now be assessed and deflected using your transaction receipts.

​
Fraud Prevention — Mastercard First Party Trust

Mastercard’s First Party Trust service is now supported on the Consumer Clarity integration. When a cardholder disputes a charge claiming fraud, Mastercard looks up the disputed transaction plus two of the cardholder’s older undisputed transactions and compares identity fields across the three receipts — enough matches confirm the disputer is the genuine customer, and the dispute is assessed as first-party fraud.
  • New FIRST_PARTY_TRUST channel value on fraud_prevention.mastercard_consumer_clarity.type — each of the three lookups is recorded on its payment and delivered on the payment.updated webhook, like every other Consumer Clarity channel.
  • Richer receipts for FPT matching. Receipts now additionally carry a deterministic per-customer device fingerprint, account phone, account creation date, billing name, and digital-delivery details — raising the chance the three lookups find matching fields.
  • No integration work required — the receipt is built from data you already provide. See Mastercard Consumer Clarity.
​
Client SessionAPI
Retrieve an existing client session by its ID.

​
Get a client session

GET /client-session/{id} returns the full client session object for a given ID — customer, plan, subscription, payment, and currency details — the same shape returned when you create or update a session. Use it to read back a session’s current configuration without recreating it.Available in API versions 1.0.0 and 2.0.0. See Get a client-session.
​
SubscriptionsAPI
Reactivate a cancelled subscription while its paid period is still active.

​
Reactivate cancelled subscriptions

PATCH /subscriptions with status: active now reactivates cancelled subscriptions, not just scheduled_for_cancellation ones. What happens depends on the paid period (current_period_end):
  • Paid period still active — the subscription returns to active with no new charge, restoring access for the remaining paid period (the same way a scheduled_for_cancellation reactivation works).
  • Paid period has ended — PayNext attempts an immediate charge on the saved payment method: success → active with a new billing period; failure → past_due (standard dunning, access not restored).
A single subscription.updated webhook reflects the resulting status.See Reactivate.
​
CheckoutWorkflowsDashboardSubscriptions
Added country-conditional card-network restrictions in Checkout, workflow version comparison, an MRR Overview chart, and saved views for custom dimension charts.

​
Restrict card networks by country

Checkout now lets you control which card networks are accepted per payment method, with an optional per-country override. Each of Apple Pay, Google Pay, and Card carries an Accepted card networks set, plus country-conditional rules: accept only specific networks when the customer’s country is in a chosen list. The method stays visible to everyone — only the accepted networks change for customers in a restricted country; everyone else pays exactly as before.
  • The restriction is applied consistently across Apple Pay, Google Pay, and Card, so a customer can’t bypass it by switching method.
  • For wallets, only the allowed networks are selectable, and a non-allowed card can’t be used to pay.
  • For card payments, a card of a disallowed network is rejected before any payment attempt, with clear “not supported” feedback.
  • Card networks default to Visa + Mastercard when nothing is configured.

​
Compare workflow versions

Workflows now have a built-in Compare mode that shows what changed between any two versions of a workflow, directly on the canvas. Pick a base (older) version and a compare (newer) version, and every change is highlighted by color: added (green), modified (yellow), removed (red), and transient (gray dashed — steps that were added and then removed again between the two versions).
  • A Changes panel lists every change with a per-type count and a color legend; clicking a change jumps to it on the canvas.
  • Hide transient shows only the net difference between the two versions.
  • Modified steps show their field-level changes in plain language (for example, Primary processor: Nuvei CC → Nuvei CC MX), with an optional per-version history.
  • Changes inside conditions and splits are shown per route.
  • Copy a link to reopen the exact same comparison.
Compare mode is read-only, and steps that were only moved are not flagged as changes.

​
Dashboard — MRR Overview

Added an MRR Overview chart on the Billing tab: monthly recurring revenue over time, stacked by subscription status — Active, Past-Due, and Scheduled Cancellation — with a Total MRR line on top. Trial subscriptions are excluded.
  • The headline shows current Active MRR with a previous-period trend comparison; the at-risk segments (Past-Due, Scheduled Cancellation) are visually de-emphasized.
  • Granularity switch: day / week / month / quarter.
  • Hover shows per-segment MRR and subscription counts alongside the total.

​
Dashboard — Saved views for custom dimension charts

You can now save a custom dimension chart’s configuration as a named saved view and reuse it later, instead of re-adjusting every setting by hand. A view captures the selected dimensions and their order, the sort column and direction, and the visible columns.
  • Save as, switch between saved views, update the active view, rename, and delete.
  • Saved views are stored per user and organization in your browser, so they are not shared across devices or browsers.
​
PaymentsAPI
Added custom pricing for one-off payments.

​
Custom pricing for one-off plans

You can now override a one-off plan’s configured amount for a single payment by passing a price object ({ "amount", "currency" }). Every other setting—name, tax behavior, enabled payment methods—is still inherited from the plan; only the amount and currency change. This is useful for variable-amount charges (donations, top-ups, quotes) without creating a plan per price.
  • Set plan.price when creating a client session for SDK checkout, or send a top-level price on POST /payments for API-only charges.
  • Supported for one-off plans only—passing price with a recurring plan returns 400.
  • The custom price takes precedence over the default and any localized country-specific price. It’s sent from your server, so the browser SDK cannot alter it.
See Custom Pricing.
​
PaymentsDashboardWorkflowsFiltersAPI
Added one-time Pix payments, a Dunning analytics tab, ARPU cohort analysis, unified dashboard filters, and new 3DS filtering options.

​
One-time Pix payments

Pix now supports one-time payments in addition to recurring Pix Automático. The flow is selected automatically by plan type:
  • One-time plans run a single Pix charge with no mandate and no recurring billing.
  • Recurring plans continue to use Pix Automático unchanged.
One-time Pix charges no longer affect an active Pix Automático subscription’s saved mandate, so recurring billing stays intact when a customer makes a one-off payment.

​
Dashboard — Dunning tab

Added a new Dunning tab with a Dunning Waterfall table: subscriptions entering and recovered per dunning attempt, cumulative recovery rate by count and amount, average days between attempts, and final lost volume.

​
Dashboard — ARPU cohorts

The Customers tab is now Cohorts and includes an ARPU (average revenue per user) heatmap with its own filter set, including customer-attribution and UTM filters.

​
Dashboard — Charts and filters

  • The Failed, Blocked, and Incomplete charts on the Payments tab and the Tax Submission Rate chart on the Tax tab are now combo charts — bars for absolute counts and a line for the rate on a second axis.
  • Dashboard analytics now share a single set of filters across all tabs (Payments, Declines, 3DS, BIN Analysis, Tax), sorted alphabetically. Active filters display human-readable labels.
  • Added two Tax tab filters: Tax Error Code and Tax Error Message.

​
3RI in the 3DS Auth Flow filter

Added 3RI as an option in the 3DS Auth Flow filter, so you can isolate requestor-initiated (merchant-initiated) 3DS authentications.

​
Masked API key value

The API Keys list now shows a masked key value (first 7 and last 5 characters, e.g. zpka_54••••e4f2a) to Admins. The full key is still shown only once, at creation.

​
Other improvements

  • The Setup Merchant page now validates each field inline with specific messages instead of a single generic error.
  • Publishing a workflow updates its status immediately, without a page refresh.
  • Dashboard Settings fixes: a tab whose last chart is hidden now auto-hides; reloading on a hidden tab redirects to the first visible tab; and the granularity selector shows full labels (Daily, Weekly, Monthly, Quarterly).
​
SDKCheckoutDevelopers
SDK 1.0.19 adds runtime control to gate payment buttons behind your own consent flow.

​
Gate payments with paymentsEnabled

The web SDK now accepts an optional paymentsEnabled flag (defaults to true). When set to false, every payment button is gated:
  • Tapping any button (Google Pay, PayPal, Apple Pay, card, etc.) does not start a payment and does not open any provider sheet or popup.
  • The card and Pix forms can still expand, but submitting them is blocked.
  • Buttons render identically — there is no visual disabled state.
Toggle the state at runtime — without re-mounting — with checkout.setPaymentsEnabled(enabled).

​
New onCheckoutBlocked callback

When a user taps a button while payments are disabled, the SDK fires onCheckoutBlocked with { paymentMethod, cardType }. Use it to react to the blocked attempt — for example, highlighting your own terms/consent checkbox.Existing integrations are unaffected: omitting paymentsEnabled keeps the normal payment flow. See Gate Payments Behind a Consent Checkbox.
​
WorkflowsSubscriptionsDashboard
Added plan switching in post-payment workflows, Split node improvements, and dashboard customization.

​
Plan switching in workflows

Payment Status Changed workflows can now switch a subscription to a different plan as a recovery action after failed or declined payments.
  • New condition: Current plan is — evaluates the current subscription plan at execution time, with equal, not equal, one of, and not one of operators.
  • New action node: Change Subscription — permanently switches the subscription to the selected plan. The subscription keeps its current currency; if the target plan cannot be applied for that currency, no change is made.
  • The current dunning schedule is not affected — future billing after dunning uses the new plan.
Both are available only in workflows started by the Payment Status Changed trigger.

​
Split node improvements

  • Route-level metadata can now be configured directly on the Split node — no extra Set Metadata nodes needed for route tagging.
  • New Preserve route assignment (CIT only) option: repeated CIT attempts in the same checkout session reuse the previously assigned route instead of being redistributed.

​
Dashboard settings

Admins can now customize the dashboard for their organization:
  • Hide or reorder dashboard tabs.
  • Hide or reorder chart cards within each tab.
  • Settings are organization-wide and apply to all members.
​
APISearchSubscriptionsDevelopers
Released API version 2.0.0. This version adds a search query language on the list endpoints, returns a consistent search envelope, and consolidates the subscription cancellation endpoints.

​
Opt in with the X-API-Version header

Set the X-API-Version: 2.0.0 header on every request to use this version. Without it, endpoints keep their 1.0.0 behavior and response shape, so existing integrations are unaffected until you opt in.

​
Search on list endpoints

GET /payments, GET /customers, GET /subscriptions, and GET /plans now accept a single query parameter written in the PayNext search query language, plus page and limit for pagination. The legacy per-field filter parameters — payment_status, amount_from, amount_to, created_from, metadata_in, subscription_status, and the rest — are removed in favor of the query language.For query syntax, fields, and examples, see Search.

​
Consistent search envelope

The list endpoints now return a standard envelope instead of a bare array:
  • object — the result type
  • data — the matching records
  • total_count — total number of matches
  • has_more and next_page — pagination cursors
  • url — the request path

​
Subscriptions — list endpoint moved

GET /subscriptions/search is replaced by GET /subscriptions, matching the search pattern used by the other list endpoints.

​
Subscriptions — one cancellation endpoint

POST /subscriptions/schedule-cancel/{id} is removed. POST /subscriptions/cancel/{id} now takes a required type field that routes between the two strategies:
  • cancel_immediately — transitions the subscription to cancelled right away.
  • schedule_cancellation — marks it for cancellation at the next billing date. This is idempotent if a scheduled cancellation already exists.
​
FiltersWorkflowsDevelopersPermissions
Added card-based routing conditions, role-based API key access controls, and API key usage visibility.

​
Card funding type and card segment

Two new fields are now available for filtering payments and configuring workflow conditions: Card funding type and Card segment. Both apply to card, Apple Pay, and Google Pay payment methods.Card funding type values: Debit, Credit, Prepaid, Deferred Debit, Charge Card.Card segment values: Consumer, Business, Commercial, Government, Payouts, General Purpose.
  • Payments page: both fields are available as filters with one of, not one of, is not null, and is null operators.
  • Workflow Builder: both fields are available as conditions with equal, not equal, one of, and not one of operators.

​
API Keys — role-based access

Access to API keys is now controlled by role:
  • Member role: API key values are hidden and key creation is disabled. Integration credential fields are read-only.
  • The full API key value is shown only once — immediately after it is created. A warning at creation prompts you to copy and store it securely; it cannot be retrieved afterward.

​
API Keys — usage visibility

The API Keys table now shows two additional columns:
  • Last used — date the key was last used to authenticate a request. Shows — if the key has never been used.
  • Created by — name and email of the user who created the key. Keys created before this update have no recorded author and will always show —.
​
Fraud PreventionMastercardAPIFilters
Mastercard Consumer Clarity is now live—Mastercard’s equivalent of Visa Order Insight, surfacing the transaction receipt to cardholders to deflect friendly fraud before disputes are filed.

​
Mastercard Consumer Clarity

Mastercard Consumer Clarity enriches the transaction receipt a cardholder sees—inside their mobile banking app or when they call their bank about a charge. The cardholder recognizes the charge, and friendly-fraud disputes on Mastercard are defused before they’re filed. Once enrolled (by statement descriptor), the integration is fully managed—no code changes required. See Mastercard Consumer Clarity.
  • New fraud_prevention.mastercard_consumer_clarity payload. Every lookup is written to the payment as a sub-object with type (the lookup channel—DIGITAL, CALL_CENTRE, MASTERCOM, or TRANSACTION_DATA), insight_id, and updated_at, and delivered on the payment.updated webhook.
  • Payments filter. Added a Fraud Prevention – Mastercard Consumer Clarity Channel filter on the Payments page. Supports one of, not one of, null, and not null. Values are sourced live from payment data.
  • Payment timeline. Consumer Clarity events now appear as Mastercard Consumer Clarity (<TYPE>), alongside existing Visa Order Insight and RDR rows.
  • Subscriptions are unaffected. A Consumer Clarity lookup is informational—it does not cancel or change the subscription, unlike a Visa Order Insight call-centre lookup.
​
DashboardSubscriptionsFilters
Added a custom analytics tab, new dashboard filters, and a plan change mode for subscriptions.

​
Dashboard — Custom tab

A new Custom tab is now available on the Dashboard. It provides a flexible dimension table where you can break down payment metrics by up to three dimensions simultaneously — processor, card network, issuer country, BIN, currency, and more. Columns are sortable and include key counts, amounts, acceptance rate, decline rate, and refund rate.

​
Dashboard — BIN Analysis

Added Acceptance Rate by Merchant Account and Card Network heatmap to the BIN Analysis tab. Shows acceptance rate per merchant account broken down by Visa and Mastercard, with color indicators for performance thresholds.

​
Dashboard — Filters

  • Added Dunning Attempt filter on Payments, 3DS, and Declines tabs.
  • Added Amount (USD range) filter with predefined brackets.
  • Added Statement Descriptor filter.
  • Added Currency Code filter.
  • Decline Advice Code, Decline Code, and Decline Message filters are now available on Payments, 3DS, and Declines tabs.

​
Subscriptions

  • Added change_mode field to the scheduled plan change flow on the PATCH subscription endpoint: next_billing_date (default) applies the change at the next billing date, immediate applies it now with no charge and recalculates the next billing date.
  • Creating a client session with proration_billing_mode: prorated_immediately when the prorated amount is below $0.50 now returns a 400 error instead of attempting a payment that would fail at the processor.
​
WorkflowsCascadingSubscriptionsAPI
Added declined payment cascading, new workflow routing conditions, PII erasure support, and subscription metadata updates.

​
Declined payment cascading

Workflows can now cascade to another processor after an unsuccessful authorization within the same payment flow. If conditions match after a decline or failure, the workflow executes another authorization attempt on a different processor without creating a new payment.Existing payment outcome conditions (decline code, advice code, decline message, failure reason, past due attempt number) are now also available for cascading routing.Available for MIT routes only:
  • Last Used Processor — processor used in the last successful authorization for this user
  • Last Used Merchant ID — Merchant ID used in the last successful authorization for this user
Current Processor and Merchant ID have been removed as payment workflow conditions and replaced by the two fields above.Other changes:
  • Use merchant from CIT toggle is renamed to Use last successful processor.
  • Payment timeline now shows all authorization attempts in sequence when cascading occurs in the same payment flow.
  • All authorization nodes within a cascading flow must use the same 3DS mode — inconsistent configurations block Save / Publish.

​
Customer API

  • PATCH customer endpoint now supports updating email, full_name, phone, address, and metadata.fingerprint.

​
Subscriptions API

  • Update Subscription endpoint now accepts a metadata field. Changes emit a single subscription.updated event.
​
WorkflowsCheckoutDashboardFilters
Improved organization navigation, workflow usability, Fraud Prevention filtering, and added refund visibility to the Dashboard.

​
Workflows

  • Condition details are now visible in View mode on hover — no need to enter Edit mode to inspect conditions.
  • Deleting the last active workflow for a payment method now shows a confirmation modal and immediately disables that method in Checkout.

​
Dashboard

  • Added Unsettled Refunds stacked bar chart on the Payments tab, showing refund breakdown by status (Settling / Settled).

​
Filters

  • Fraud Prevention filter on the Payments page now works as a simple presence check — use Is null / Is not null to filter payments that have or don’t have fraud prevention data attached.
​
WorkflowsSubscriptionsNotificationsFilters
Added post-payment workflow automation, in-app notifications foundation, and several dashboard usability improvements.

​
Workflows and subscriptions

  • Added the new Payment Status Changed workflow trigger.
  • Workflows can now run on Payment Failed or Payment Declined outcomes.
  • Added payment outcome conditions:
    • payment decline code
    • payment advice code
    • payment decline message
    • payment failure reason
    • past due attempt number
  • Added subscription cancellation actions:
    • cancel immediately
    • schedule cancellation

​
Notifications

  • Added organization-scoped in-app notification delivery through the notifications feed.
  • Added the foundation for future operational alerts, product updates, and Slack-based notifications.

​
Dashboard improvements

  • Payments page now supports a Failure Reason filter.
  • Newly selected filters now appear at the top of the applied filters list.