Skip to main content
​
APIPaymentsSubscriptionsDashboard
Every endpoint now answers an unparsable request body the same way, the payments and customers list filters apply a bound of 0, and a missing workflow returns 400 instead of 500.

​
Unparsable request bodies

The remaining endpoints that can’t parse the request body now answer 400 with the single message invalid request body. Before, they echoed the parser’s own error text, which could include a fragment of the body you sent. This now also covers:
  • Client session create and update, which answered Invalid request body with a capital I.
  • The list endpoints that accept a search body (GET /payments, GET /customers, GET /plans, GET /subscriptions and their /search and /opensearch variants), which answered invalid JSON body.
  • The Worldpay inbound webhook, which answered invalid Worldpay XML: ….
  • Inbound webhook endpoints with an unsupported content type, which answered Unprocessable Entity.
Two endpoints that accept only one field now answer a fixed hint instead of the parser text, so you still learn what to fix without the response echoing your request:
  • POST /payments/refund/{id} answers request body may only contain "metadata" when the body carries any other field.
  • Subscription cancel (POST /subscriptions/cancel/{id}, v1 and v2) answers request body may only contain "type" when the body carries any other field.
A syntax error on those two endpoints answers invalid request body. A body that parses but fails validation is unchanged: it still answers 400 with Invalid request body and validation_errors. If your integration matched on the parser text, match on the status code or on these fixed messages instead. See Errors.

​
List filters apply a bound of 0

The payments list filters amount_from, amount_to, amount_equal, and amount_not_equal, and the customers list filters total_spend_from, total_spend_to, total_spend_equal, and total_spend_not_equal, now apply a bound of 0. Before, 0 was ignored, as if you hadn’t sent the filter.
  • “Equals 0” lists only payments with a zero amount, or customers with no settled spend.
  • The lower bound stays inclusive: amount_from=0 and total_spend_from=0 still include them. To exclude them, use amount_from=1 or total_spend_from=1, or amount>0 in the search query language.
This is a behavior change. If your integration sent 0 to mean “no bound”, it now gets a filtered list. For example, amount_from=100&amount_to=0 used to mean “100 or more” and is now an empty range. In the search query language, amount:0, -amount:0, amount<1, and total_spend:0 used to be dropped and now filter. Omit the parameter to leave a side unbounded.

​
Payments and subscriptions

  • Creating a subscription or a payment for an organization with no active workflow now returns 400 with the message no active workflow for this organization. Before, it returned 500.
  • A one-off POST /payments with a custom-price currency in lower case, such as jpy, now creates the payment in the upper-case code (JPY). An invalid currency code still returns 400.
  • subscription.past_due.max_attempts_count now reports your organization’s dunning ladder (the number of the last attempt), the same value as GET /subscriptions/{id}. This applies to GET /payments/{id} with include=subscription,past_due_attempt, the payment webhooks, and customer reads with include=subscriptions. Before, these showed the default ladder length.

​
Fixes

  • A customer’s details in the Dashboard no longer show data from a request made with different include options.
  • Searching BINs by issuer now treats _ and % as literal characters instead of wildcards.
​
MCP
Refunds, subscription cancellations, and API key revocations now wait for your approval when you sign in to the account server. Your AI tool gives you a link or opens it in your browser, and you approve or reject the change on a PayNext page.

​
Approve a change in your browser

Open the link in a browser signed in to PayNext, check the change, and select Approve or Reject. Approve runs what the page shows at most once, after PayNext checks it again, and Reject changes nothing. The link works for 10 minutes. Your AI tool reports the result. If it doesn’t, send it any message. See Approve a change in your browser.

​
See your approvals

The paynext_approvals_query tool lists the changes waiting for your approval in this session, and how each ended. It’s available to every role and needs only read access.

​
Subscription cancellation

When you sign in, paynext_subscription_cancel cancels a subscription as the Dashboard does. A trial or active subscription ends at the end of the billing cycle, and a past-due one ends immediately. Any other status is refused. See What you can do.Connections with an API key work as before: nothing waits for approval.
​
API
A request body that isn’t valid JSON now gets the same answer on every write endpoint of the API.

​
Malformed request bodies

POST /subscriptions, PATCH /subscriptions, POST /payments, and PATCH /customers/{id} now answer a body that can’t be parsed as JSON with 400 and the message invalid request body, the same answer POST /payments/card and POST /customers already give. Before, these four endpoints echoed the parser’s own error text, which could include a fragment of the body you sent. Nothing changes for a well-formed body: field validation errors keep their messages. If your integration matched on the parser text, match on the status code or on invalid request body instead. See Errors.
​
PaymentsWebhooksAPI
Disputes now cover Unlimit, Stripe disputes resolved through Visa Rapid Dispute Resolution are flagged, and a lost dispute now reverses the payment’s sales tax.

​
Unlimit disputes

Unlimit disputes now appear in PayNext, in the Disputes API and in the dispute webhooks. Unlimit doesn’t send dispute notifications, so a new dispute can take up to about an hour to appear, and a status change up to about an hour, or about six hours while the dispute is under review. An Unlimit retrieval request that closed as PREVENTED becomes LOST if a chargeback follows it, and you receive lost. See Disputes, Unlimit and Event Types.

​
Visa RDR on Stripe disputes

The is_visa_rdr detail is now also set on Stripe disputes that Stripe resolved with a refund before they became a chargeback, and on Unlimit disputes reported under Visa RDR. Because the detail can be added to a dispute that is already final, you may receive payment_v2.dispute.updated for an older dispute. See Dispute details.

​
Sales tax reversed on lost disputes

When a dispute ends LOST or ACCEPTED, PayNext now reverses the payment’s sales tax with Numeral, as it already did for a refund, and the payment’s tax.status becomes reversed. If the dispute is later won or reopened, the reversal is undone and tax.status returns to submitted. An inquiry (a dispute at the RETRIEVAL stage) and a PREVENTED dispute never reverse tax, and a payment that is both refunded and lost in a dispute is reversed only once. A dispute resolved in an earlier month is reversed with today’s date. No webhook is sent for the tax change itself; read it from the payment. See Tax.
​
MCPDashboard
The account server can now read every chart on the Dashboard’s Overview, Billing, Risk, Disputes, and Revenue recognition tabs. Ask your AI tool about a figure, and the answer matches the chart on the same tab with the same settings. See Dashboard figures.

​
Overview and Billing

Ask for authorized, settled, or unsettled volume, the acceptance rate, the high-risk rate, created payments, tax, the 3D Secure authentication rate, or recovered revenue. On the Billing side, ask for active subscriptions, MRR, ARR, subscription growth, average revenue per customer, dunning recovery, trial activation, created or cancelled subscriptions, recovered subscriptions, or retention cohorts. Where a chart has a headline, the answer includes it with the previous period and the trend.

​
Risk and Disputes

Ask for early fraud warnings, Ethoca and Visa CDRN alerts, Visa RDR, Visa CE 3.0 prevented disputes, Order Insights, or Consumer Clarity, by type, merchant account, or processor. On the Disputes side, ask for the dispute rate, lost or won disputes, the win rate, or the disputes open now and their response deadlines.

​
Revenue recognition

Ask for a month’s period summary on the accrual or cash basis, cash vs accrual, the deferred revenue roll-forward, the revenue waterfall, revenue by plan or billing period, journal entries, or monthly totals. The waterfall answer includes its Total row when the period has two or more booked months, as on the Dashboard.The new tools are available to Admin and Member roles when you sign in to the account server. They read data and never change it.
​
PaymentsSubscriptionsStripe
UPI is now available as a payment method, and Indian-issued cards can now be charged on a recurring basis.

​
UPI payments in India

UPI is now available as a payment method for one-time payments and subscriptions, in INR for customers in India. Customers enter their UPI ID or scan a QR code, then approve in their UPI app with their UPI PIN. For a subscription, that same approval also sets up UPI AutoPay, so later renewals don’t need a new approval. See UPI for setup, amount limits, and testing.

​
Recurring charges on Indian-issued cards

Visa and Mastercard cards issued in India are now supported through Stripe, with the bank’s authentication step at checkout. For a subscription, the first payment also registers an e-mandate, so renewals can be charged without the customer present. The bank notifies the customer before each debit, so a renewal can take up to about a day to settle. To register the e-mandate, set 3D Secure to Processor 3DS on the Authorize Payment node of your workflow. See Indian-issued cards for the e-mandate limits and what happens when no e-mandate is registered.
​
Dashboard
The Revenue recognition report now covers whole months picked from a list of periods, opens the payments behind its figures, and explains the gap between cash and revenue. See Revenue Recognition.

​
Month periods

The Revenue recognition tab now picks whole months: This month, Last month, Last 3 months, Last 6 months, Last 12 months, Last 24 months, or Year to date. It opens on Last 6 months. Last month is the previous calendar month; every other period ends with the current month. The other Dashboard tabs keep their date range.

​
See the payments behind a figure

Click a figure to open the payments behind it for that month. In the Period summary, that works for Processor receivable, ending balance, Cash collected, Cash refunded, Pending cash (in flight), Tax collected, Tax refunded, Deferred change from new billings, and Pending revenue (in flight). In Cash vs accrual, it works for Cash collected, Cash refunded, and Pending revenue (in flight) on each month row, the MTD row included. Each list uses the report’s period and your Dashboard filters, and its footer shows the number of payments and their total. See See the payments behind a figure.

​
Accrual minus cash, explained

Cash vs accrual now splits Accrual minus cash into Released from deferred revenue, Change in receivable, and Tax, which add up to it together with Other. Other appears only when the payment data leaves a gap, such as a settled payment without a settlement date. The card is now a table, without the chart.

​
Processor receivable roll-forward

The Deferred revenue roll-forward also rolls the processor receivable forward month by month, with Receivable starting balance, Booked, including tax, Settled, and Receivable ending balance.

​
Month to date

The current month is labeled MTD, for example Oct 2026 MTD. Every figure of it, including the payment lists and the CSV exports, stops at the end of today (UTC). It is a row like the other months and is part of the Total. Its figures are final only after the month closes and late settlements have landed. In Cash vs accrual and the waterfall, the Total row appears only when there are two or more months.

​
Removed

The Suggested refund reserve memo row in the Period summary and the MoM net cash and MoM net recognized revenue columns in Cash vs accrual are gone. The report books no estimate for future refunds; whether to record a refund reserve is your accounting policy.

​
Export and layout

Every card has an Export button that downloads its table as a CSV. In the Period summary, choose Summary (this month) or Journal entries (all months). Future unwind of ending balance now sits next to the Period summary.

​
Renamed figures

On the cash basis, Refunds is now Cash refunded. In Revenue by plan, Collected is now Revenue booked. In the Period summary, the memo section Pending settlement, not yet booked is now Memo, not booked. Pending revenue (in flight) is now the revenue, excluding tax, of payments authorized in the month that are still authorized or settling, so it matches the payments listed when you click it.
​
MCP
The account server can now search and filter plans and grant the Disputes permission on API keys. This release also changes what happens when your sign-in ends, and fixes several answers.

​
Plans

Search plans by name or ID, and filter them by type, billing interval, currency, tax collection, and trial. The filters match the Plans list in the Dashboard. A new name is now optional when you duplicate a plan: without one, the copy is named after the original with “(Copy)” added.Changing a plan’s price, billing interval, or trial now leaves its tax collection untouched. Before, a tax change made in the Dashboard at the same moment could be overwritten. After such a change, the plan’s Last Updated date, and so its place in the Plans list, stays as it was. Creating or updating a plan with a price taken from another plan now works when that plan has no country-specific prices. Before, the request was refused.

​
Payments and customers

An Amount or Total Spend filter equal to 0, or one whose upper end is 0, is now refused. Before, PayNext ignored it. The currency of a Total Spend filter must be a three-letter code. A search in the Merchant filter’s values now narrows them by name. Before, every value came back. Your AI tool now groups payment analytics by calendar month when you ask. A payment timeline’s raw request and response data withholds more card, wallet, and 3D Secure details.

​
API keys

Grant the Disputes permission (None / Read) when you create or update a key. Updating a key now changes only the permissions you name, and the others keep their level. Before, any permission you left out was set to None. The one exception is a key created before March 16, 2026 with no permissions set, which has full access: updating it keeps only the permissions you name.

​
Sign-in and organizations

If your PayNext sign-in ends, changes stop at once, reads stop within a minute, and your AI tool asks you to sign in again. A sign-in ends when you sign out in the browser you signed in with, or when it expires. Switching organizations doesn’t bring the session back. If your sign-in can’t be checked for a moment, your AI tool asks you to try again in a minute. Nothing runs until then, and you don’t need to sign in again. If an organization switch ends, your session stays in that organization but nothing runs until you switch again. Before, you were asked to sign in again.The browser link for switching organizations now tells you when your sign-in has ended. If your sign-in can’t be checked at that moment, the link still works: try it again in a minute. If you deny access on the PayNext sign-in page, the sign-in stops and PayNext tells your AI tool. The approval screen now names everything read and write access cover, including API keys.

​
Workflows

Pages of workflow runs no longer shift while your AI tool reads through them. The run counts stay live. When you ask for running runs only, the answer says if their number is a minimum rather than an exact count. When a list is too long to page to the end, the answer says so and suggests narrower filters.

​
Connections with an API key

For security, a search that mentions network_token is refused, and so is sorting by a field whose value is always hidden. See Connect your software with an API key.See MCP Server for every tool and the roles that can use it.
​
PaymentsDashboardFilters
The Payments page has a new Disputed view that lists only the payments with a dispute.

​
Disputed view on Payments

Open Payments → Disputed in the sidebar, or the Disputed tab on the Payments page. The most recently disputed payments come first, and the table shows each payment’s latest dispute status, stage, and date. With dispute filters applied, the table shows the latest dispute that matches them, and the list is ordered by that dispute’s date.

​
Dispute filters

Filter the view by Dispute Date, Dispute Status, Dispute Stage, and Dispute Reason, alongside Payment Method, Processor, and Merchant. A payment matches when one of its disputes meets all the dispute filters you set. The is after and is before options of Dispute Date include the chosen day, counted in UTC. Payment Date, Amount, Currency, and Refund are under More filters. See Find disputed payments in the Dashboard.
​
WorkflowsSubscriptionsCheckout
Workflows have a new Split Trial node. It charges a subscription’s trial price as two payments: the first at checkout and the second right after it is authorized, to the same payment method. See Split Trial.

​
Split a trial in your workflow

Add the node before Authorize Payment on the paths you want to split. The checkout still shows the full trial price, and the plan keeps it. Only the first payment of a new subscription made with a new card through Cards, Apple Pay or Google Pay is split. Every other payment passes through unchanged.

​
Current plan in conditions for CIT routes

The Current plan condition is now available in workflows triggered by Payment Pending, so you can route a customer’s first payment by the plan they are buying. When you use it to choose Split Trial paths, select only plans that have a trial and are not archived.

​
Before you turn it on

If your backend already charges the second part of the trial, stop that charge first, or the customer pays twice. See Split Trial for the full rules, including how the trial price is divided.
​
IntegrationsPaymentsDashboard
You can now turn off 3RI for a single processor. 3RI stays on by default for every processor that supports it.

​
3RI setting per processor

Open the processor’s 3DS settings, switch off 3DS Requestor Initiated (3RI) and save. With 3RI off, recurring charges on that processor go out without 3DS and without liability shift. Payments where the customer is present are not affected, and only Admins can change the setting. See Turn off 3RI for a processor.
​
IntegrationsPayments
Braintree can now charge each payment in its own currency. Map each currency you accept to its own merchant account, and PayNext sends the payment to the right one.

​
Merchant accounts by currency

The Braintree integration form has a new section for this. Your Merchant ID stays the USD account. Click Add currency to pair another currency with the ID of its merchant account in Braintree, for example EUR with your euro account.

​
Set up the pairs

Add a row for each currency you accept and save. Existing integrations keep only the default row until you add a pair. See Braintree for the setup steps.
​
PaymentsWebhooks
Dispute webhooks now cover more of a dispute’s lifecycle, including disputes that reopen or change after they’re resolved. See Disputes.

​
New dispute webhook events

Two new v2 event types report dispute changes that previously sent no webhook. payment_v2.dispute.evidence_submitted fires when the status changes to EVIDENCE_SUBMITTED. payment_v2.dispute.updated fires when stage, reason, disputed_at, respond_by or details changes and the status doesn’t. Endpoints subscribed to selected event types receive them only after you add them. See Event Types.

​
Reopened disputes

payment_v2.dispute.reopened now also fires when a dispute moves from a final status back to NEEDS_RESPONSE, EVIDENCE_SUBMITTED or UNDER_REVIEW. This happens when PayPal reopens a resolved dispute, for example after an external chargeback, a reason change or an appeal. A reopened dispute has no resolved_at until it reaches a final status again. A reopen into EVIDENCE_SUBMITTED or UNDER_REVIEW sends the event for the new status plus payment_v2.dispute.reopened.A resolved PayPal dispute can also move to a different final status, for example from WON to LOST, and a Stripe dispute in LOST can later become WON (a late win). In both cases you receive the event for the new status, and resolved_at keeps its original value.

​
Stripe case type

Stripe dispute details can include stripe_case_type. A Stripe dispute recorded before this change gets it on its next change if it’s still open. One that was already final doesn’t, unless a LOST dispute later becomes WON. See Dispute details.
​
PaymentsWebhooksAPIDashboardFilters
PayNext now tracks disputes across processors. You can follow them through webhooks, a dedicated Disputes API and the Dashboard. See Disputes.

​
Dispute webhooks

PayNext sends v2 webhooks for the dispute lifecycle. The event types are payment_v2.dispute.created, .reopened, .under_review, .won, .lost, .accepted and .prevented. Subscribe to them like any other event type. See Event Types.

​
Disputes API

Two new endpoints return your disputes: GET /disputes lists them and GET /disputes/{id} retrieves one. An API key restricted by scope needs the new disputes scope, which you can grant on the Developers page. See API Keys.

​
Disputes tab

The new Disputes tab on the Dashboard shows your dispute rate, lost volume, win rate and open disputes by status. Choose the date range and granularity, then narrow the charts by payment method, processor, merchant, dispute stage, dispute reason and customer country.

​
Dispute filters on Payments

The Payments page has two new filters under More filters: Dispute Status and Dispute Stage. Use them to find the payments that have disputes.
​
SDKCheckoutDevelopers
The PayNext checkout now renders inside a secure iframe, so card details and payment provider scripts stay separate from your page. SDK 2.0.0 is a major release with breaking changes.

​
Checkout in a secure iframe

The checkout loads from PayNext, and scripts on your page can no longer read what customers enter. You mount the checkout, configure it, and receive callbacks the same way as before. The change applies to every integration.

​
New styling model

Your page’s CSS no longer reaches the checkout, so you style it only through the SDK configuration. See Customize the Appearance for every style option.

​
Payment method click callback

Because the checkout is in an iframe, your page can no longer watch clicks on the payment buttons. The new onPaymentMethodClick callback reports each click with the payment method, for example { paymentMethod: 'APPLEPAY' }, so you can keep tracking which method customers choose. It is available in SDK 2.1.0. See Customize Checkout Behavior.

​
Success screen background

The new --paynext-sdk-success-bg CSS variable sets the background of the success animation. It is available in SDK 2.0.1. See Theme Support.

​
Migrate to SDK 2.0

The migration guide covers the styling changes, the Content Security Policy update, container sizing and Apple Pay on older Safari versions. See Migrate to SDK 2.0 for the step-by-step guide with before and after examples.
​
MCP
The account server now covers plans, Card BIN lists, workflows, checkout, API keys, and integrations, so you can do more of your Dashboard work by chatting with your AI tool. These tools are available to Admin and Member. Support Specialist keeps payments, customers, refunds, and subscription cancellations.

​
New tool names

Every account server tool now starts with paynext_, for example paynext_payments_query and paynext_payment_refund. The previous names, such as get_payments and refund_payment, no longer exist. If your AI tool calls an old name, the answer gives it the new one. Ask your AI tool to list its tools again to see them all.

​
Payments and customers

Search payments and customers with the same filters as the Dashboard, and ask which values a filter accepts. To read one payment or customer, give its ID. The separate by-ID tools are gone.

​
Refunds

Refunding a payment now also cancels its subscription by default, the same as the Dashboard’s refund dialog. To keep the subscription, say so.

​
Plans

Create a plan, change its name, price, billing interval, trial, or tax collection, duplicate it under a new name, and archive or unarchive it. For example: “Create a monthly Pro plan at 19.99 EUR with a 7-day trial.”

​
Card BIN lists

Create Card BIN lists, read their BINs, and add or remove BINs. For example: “Add these eight BINs to our block list.” Lists can’t be deleted.

​
Workflows

Read your workflows and their versions, see what changed between two versions, and review what your workflows did, with the same run totals as the Dashboard.

​
Checkout

Read your checkout’s payment methods and bot protection mode. Admins can set bot protection to Off, Shadow, or Enforce.

​
API keys

List your API keys with their permissions and when each was last used. Admins can also create keys, change a key’s permissions, and revoke keys. A new key’s value is shown once.

​
Integrations

Read your payment processors and their 3D Secure setup, your tax providers, and whether your dispute-prevention programs are working for each processor.See MCP Server for every tool and the roles that can use it.
​
DashboardPlans
The Plans list now has search and filters.

​
Search your plans

Search by plan name or ID, in full or in part — across both at once, or in just one of them. Search isn’t case-sensitive.

​
Filter the list

Filter pills sit next to the search: plan type, billing interval, currency, tax collection and trial. Combine them with a search to get straight to the plans you need.The list shows active plans by default. Your search and filters are kept in the page address, so a reload, a link you share with a teammate, or the Back and Forward buttons bring back exactly the same view.
​
PaymentsWebhooksAPISearch
Disputes from supported processors now share one dispute object, with endpoints to list and retrieve them, webhook events as a dispute moves through its lifecycle, and dispute summaries on payments.

​
Disputes API

GET /disputes lists your organization’s disputes, with filters for status, stage, and payment_id, and GET /disputes/{id} retrieves one, including processor-specific details. Every dispute carries a normalized stage, status, and reason, plus respond_by and resolved_at when set. See Disputes.

​
Disputes API key permission

Scoped API keys have a new Disputes permission (None / Read). The disputes endpoints require Disputes: Read, so existing scoped keys receive 403 until you grant it. See API keys.

​
Dispute webhook events

Seven v2 events track a dispute’s lifecycle: payment_v2.dispute.created, under_review, won, lost, accepted, prevented, and reopened. Each carries the full dispute in data.object, like other webhook events. See Event Types.GET /payments and GET /payments/{id} now include a disputes array summarizing each dispute on the payment. The dispute.status and dispute.stage search fields let you find payments by dispute. See Search.
​
WebhooksSubscriptions
Added pre-charge reminder webhooks for trials and renewals.

​
Pre-charge reminder webhooks

Two new subscription events fire 24 hours before PayNext charges a subscription, so you can remind the cardholder before the money moves:
  • subscription_v2.trial_will_end (v1 alias subscription.trial_will_end) — 24 hours before a trial converts to its first paid charge.
  • subscription_v2.renewal_upcoming (v1 alias subscription.renewal_upcoming) — 24 hours before a regular renewal charge.
Both carry the standard subscription object; read next_billing_date for the charge moment. PayNext sends the trigger; you own the customer-facing email or SMS. No reminder precedes a dunning retry, and reminders should be treated as idempotent by next_billing_date.See Event Types.
​
PaymentsSubscriptionsStripe
BLIK is now available as a payment method, and card updater dormancy windows are configurable per organization.

​
BLIK payments in Poland

BLIK is now available as a payment method for one-time payments and subscriptions, in PLN for customers in Poland. Customers approve with a six-digit code in their banking app — for a subscription, that same approval also authorizes future renewals, so later charges don’t need a new code. See BLIK for setup, limits, and how to show your own payment description in the customer’s banking app.

​
Card updater settings

The dormancy window that unsubscribes a saved card from Network Token updates and from the Card Account Updater (CAU) service is now configurable per organization, instead of a fixed 60 days shared by both. Set the Network Token window and the CAU window independently in your organization settings; leave either blank to keep the previous 60-day behavior.
​
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.