Failed payment recovery is an involuntary churn problem, not just a card-retry setting. On a marketplace platform, one failed renewal can still turn into a lost subscriber when product, engineering, and operations are not running the same recovery process.
Because payment failures map directly to involuntary churn risk, "turn on retries" is not enough. You need clear decisions on what is recoverable, who owns the next action, how the subscriber is prompted to fix payment, and how finance verifies the outcome.
This article gives embedded payments teams a seven-step execution sequence focused on operating decisions, not generic dunning advice. Each step centers on ownership, pre-launch verification, and the tradeoffs between native billing features and custom logic.
You should get three outputs from the sequence:
If you carry one rule forward, make it this: do not tune retry timing until recovery ownership and weekly success measurement are explicit.
Examples reference Stripe Billing, Chargebee, and Vindicia as practical reference points. Stripe Billing supports automatic retries for failed subscription and invoice payments, including Smart Retries and custom schedules. Chargebee defines dunning as retrying failed collections and includes customer notifications. Vindicia documents retry logic and distinguishes between retryable failures and hard failures.
Capabilities vary by integration and market, and some features can be account- or rollout-dependent, so do not assume feature parity. Stripe documents Connect implementation differences for customer-configured accounts, explicit no-retry conditions such as no available payment method and hard decline codes, and market-specific constraints such as India-issued cards. This playbook stays focused on decision logic you can verify in your own setup.
Before you copy any retry pattern, verify:
Scope mismatches are a common reporting failure. Stripe's recovery analytics cover recurring subscription payments and exclude the first invoice payment after a trial, so comparisons against broader internal failed-invoice reports can misstate recovery performance.
The goal is simple: move from failed payment event to recovered subscriber with decisions that are owned, testable, and realistic about integration and market limits.
Do not tune retry logic until recovery ownership and measurement are explicit. A failed renewal is an involuntary churn problem, so your first control is operating clarity, not another retry rule.
Assign clear accountable owners across the process, for example:
| Owner | Focus | Example action |
|---|---|---|
| Product owner | Customer path after failure | Retry, payment-method update prompt, or escalation |
| Engineering owner | Webhook and retry handling | Webhook-driven event handling, deduplication, and idempotent retry/state handling |
| Finance ops owner | Recovery reporting | Define when revenue is counted as recovered and what must appear in the ledger journal before reporting success |
Make handoffs explicit for dunning management and exception queues. Keep routine retries and reminders in the standard lane, and route mismatches, overdue high-value invoices, or missing journal outcomes to a named resolver.
Before rollout, define and freeze a small scorecard:
Use provider events and recovery analytics as anchors. Then align internal definitions so failure and recovery counts are comparable.
Every state change should be traceable from provider event to internal action to ledger journal entry on the same invoice or subscription record. "Event received" is not enough on its own, because duplicate webhook deliveries can occur.
Your checkpoint should prove that duplicate deliveries and retried requests do not create duplicate recovery actions. Finance controls should also make journal creation and processing auditable. If no team can own end-to-end recovery outcomes and review them on a defined cadence, pause rollout and fix ownership first.
This pairs well with our guide on Calculate Platform Interchange Revenue From Card Transactions and What You Keep.
Lock your baseline before you change retry logic. If you do not, recovery metrics will mix recoverable failures with stop conditions and you will lose confidence in the results.
Use a two-axis taxonomy: decline class plus account state. That gives you clear action rules instead of a long, noisy list of gateway codes.
At minimum, keep these internal classes:
Retry can stay open when the account is active and a usable payment method exists. Chargebee documents hard versus soft declines, and its Smart Retry timing varies by error type.
Keep this out of the soft-decline retry lane. Stripe lists hard declines and missing payment methods as no-retry conditions, and Chargebee states hard declines are not retried until the payment method changes.
Route this to review or to a short controlled retry lane until classification is clear. Unowned failures create avoidable reporting noise.
Then layer in account state, for example active with valid method, active with no valid method, grace period, or canceled pending reactivation. The key rule is that each class-and-state pair maps to one allowed action, such as retry, update-method prompt, pause access, or escalation.
Stripe Billing and Chargebee are not equivalent by default, so compare your current settings with the customer path you actually want before launch.
| Area | Stripe Billing | Chargebee | What to decide |
|---|---|---|---|
| Retry mode | Smart Retries or custom retry schedule | Custom retry frequency or Smart Dunning | Which timing is provider-native versus app-controlled |
| Default guidance | Recommended default: 8 tries within 2 weeks | Smart Dunning: up to 12 retries (plan-dependent) | Set your target count from baseline, not vendor defaults |
| Stop conditions | No retry when no payment method exists or issuer returns hard decline | Hard declines are not retried until payment method changes | Where to switch from retry to update-method UX |
| Availability caveat | Native in Stripe Billing | Smart Dunning availability varies by plan (docs note Performance Plan) | Confirm your intended sequence is enabled in your account |
Make analytics replay-safe from day one. Stripe notes that webhook endpoints can receive duplicate events, and idempotency is meant to prevent duplicate side effects when API requests are retried.
Before launch, define and persist an event schema for inbound callbacks and outbound recovery actions. A practical starting set is provider event ID, event type, event timestamp, a mapped internal invoice or subscription ID, and the outbound idempotency key.
Also separate provider key windows from your own replay strategy. Stripe notes keys can be pruned after at least 24 hours, and Chargebee documents a 30 minute idempotency window. If you need longer auditability, persist your own durable operation key.
Run a dry-run reconciliation before go-live so engineering event counts and finance outcomes match for the same invoice population. Treat unresolved exceptions as launch blockers.
If cash reporting depends on Stripe payouts, use payout reconciliation to tie transactions to payout batches. This matters even more if you use instant payouts, where reconciliation responsibility remains with you.
We covered this in detail in Build Plan Tiers and Add-Ons That Raise Revenue Per Platform User.
Classify failures before you tune retries. Keep soft declines in recovery, and route hard declines out of the retry lane.
Chargebee defines soft declines as temporary issues and hard declines as cases that need customer or operator intervention. Stripe Billing also treats hard declines as a stop condition, and Chargebee says hard declines are not retried until the payment method is updated. Your dunning management flow should therefore include an explicit no-retry-to-update-payment-method branch, not just retry counts.
For failed payment recovery, use three lanes:
| Lane | When it applies | Route |
|---|---|---|
| Recoverable now | Soft or temporary decline with an active account state that still permits recovery | Timed retry |
| Non-recoverable until change | Hard decline | Update-payment-method UX |
| Uncertain (controlled lane) | Ambiguous issuer feedback such as generic_decline | Controlled timed-retry or review lane |
Soft or temporary decline with an active account state that still permits recovery. Route it to timed retry.
Hard decline. Route it directly to update-payment-method UX.
Ambiguous issuer feedback such as generic_decline. Treat it as unknown, then use a controlled timed-retry or review lane instead of forcing a hard or soft label too early.
If ambiguous declines automatically inherit your default retry sequence, attempt volume can rise and reporting can get noisier.
If you run connected accounts, recovery flows should respect compliance status before money-movement decisions. Stripe Connect requires KYC before connected accounts can accept payments and send payouts, and Stripe documents risk-based KYC and AML screening for individuals and businesses.
Use a clear rule: payment recoverable and account reactivatable are separate decisions.
Publish one matrix keyed to webhook type, mapped decline class, and customer state. Include the provider event type, internal failure class, account or compliance state, allowed next action, owner, and required evidence.
Validate it with real webhook samples and duplicate deliveries. If one duplicated event can send the same invoice down two paths, fix the matrix before changing retry timing.
If you want a deeper dive, read A Guide to Dunning Management for Failed Payments.
Design retries as a deterministic state machine with replay safety first. Then choose native retries, specialist tooling, or orchestration based on how complex your routing and sequencing needs really are.
Model each invoice or subscription through explicit states such as payment_failed, awaiting_customer_action, retry_scheduled, retry_in_flight, recovered, and final_failed. That is what prevents duplicate collection when jobs rerun, webhooks are delivered twice, or operators intervene mid-flow.
Use an idempotency key on each charge attempt so the same request can be retried safely without creating a second operation. Also deduplicate webhook events, because duplicate deliveries can occur.
Re-send the same webhook event twice. Rerun the same retry job twice. Confirm you still get one charge attempt, one state transition, and one customer notification. If one path can mark an invoice recovered while another path keeps dunning active, fix state handling before tuning retry timing.
Dunning management should combine payment retries with customer communication, not just timing. For each step, define:
update payment method, confirm funds, or contact supportApply the Step 1 stop conditions consistently. If you hit a hard decline or no usable payment method, route to the update-method flow instead of auto-retrying. For ambiguous failures, use a short controlled lane with a clear ask, then expire to a final action if nothing changes.
| Path | Fits when | What you get | Watch-outs |
|---|---|---|---|
Native settings like Stripe Billing | One main processor and mostly standard subscription or invoice recovery | Automatic retries (Smart Retries or custom schedule) | Hard-decline and no-method stop conditions still need a clean off-ramp UX |
| Specialist recovery tooling | You want a dedicated recovery layer without building all sequencing yourself | Managed retry and dunning workflows | Validate processor coverage, event mapping, export detail, and ledger or support handoff |
| Custom orchestration | You need multi-processor routing or materially custom sequencing | Rule-based routing and cross-processor retry options | Higher engineering and reconciliation burden, and weak idempotency creates conflicting states faster |
If you need logic across processors or materially custom sequencing, favor orchestration. Otherwise, start with native settings and instrument them hard. Stripe documents both cross-processor routing and cross-processor retries. S&P Global highlights why orchestration demand exists: multi-processor management is complex, and "No payments provider is truly global and does everything well."
If you start with Stripe Billing, capture the identifiers needed for replay-safe operations: idempotency key, webhook event ID, internal state, and current customer action.
Before rollout, run three tests in staging or in a controlled cohort:
If any test yields duplicate charge attempts, duplicate customer notices, or retries after a stop condition, the sequence is not ready.
For a step-by-step walkthrough, see How Platform Operators Recover Failed Payouts Without Duplicate Risk.
If finance and engineering read different payment states, recovery decisions will drift. Treat Webhooks as event intake, persist accepted events into Ledger journal records, and derive wallet, dashboard, and recovery views from that same journaled timeline.
Provider callbacks are asynchronous, can be duplicated, and can arrive after UI state has changed. A single ledger-backed timeline gives finance an audit trail and gives engineering one replay-safe system of record.
Use the webhook endpoint to validate, record, and hand off events in a replay-safe path. For each accepted event, store a canonical record keyed by provider event ID. Link it to invoice, subscription, and account identifiers, then link the business effect to a Ledger journal entry, or to a journal-linked event record.
Deduplicate webhook processing by event ID before applying business changes. If finance can mark an invoice recovered while engineering still sees it as failed, your source of truth is split.
Compute wallet balances and payment status from journaled events, not raw callbacks. In ledger systems, balances are aggregations over immutable transactions, so recovery state should follow the same model.
Expect lag in read views while projections catch up. That eventual consistency is safer than showing "recovered" from one callback when a related failure or reversal has not been journaled yet.
In payment flows, processing can fail repeatedly across hops. Add DLQ handling for repeatedly failed messages and set a sane receive threshold. Setting maxReceiveCount too low, for example 1, can move transient failures to DLQ immediately.
Store enough DLQ context for replay and audit: provider event ID, event type, invoice or subscription ID, receive timestamp, processing error, handler version, and whether a Ledger journal write was attempted.
For Stripe operations, account for both windows: automatic resend of undelivered events for up to three days, and manual Events API recovery that only returns events from the last 30 days. During manual replay, use delivery_success=false. Chronological processing with ending_before and auto-pagination helps recovery, but DLQ redrive can still interleave with new traffic.
Before rollout, verify webhook dedupe and outbound idempotency together. Webhook duplicates should collapse by event ID; outbound retries should reuse the same Idempotency key.
Run one invoice through this checkpoint:
Ledger journal outcome.Idempotency key and confirm the original provider result is returned.Also protect against retention and poisoned-request edge cases. Stripe idempotency keys can be up to 255 characters and may be removed after at least 24 hours, so durable duplicate protection must live in your own records. Because the same key returns the first result, including 500 errors, do not loop forever on a poisoned key. Check journal or provider state, then acknowledge, repair, or issue a new request intentionally.
For the full breakdown, read How to Build a Deterministic Ledger for a Payment Platform.
A reliable payment timeline is not enough if the recovery experience still blocks action. Recovery slows down when subscribers see a vague failure message and ops teams work an undifferentiated backlog.
Make the next step explicit. Explain the failure plainly, then send the subscriber straight to the fix. Stripe's baseline is clear: customers should be able to confirm payments, correct failed payments, and use a direct payment-method update path so a retry can succeed.
Avoid generic "payment failed" banners with no action path. If there is a hard decline or no valid payment method on file, do not suggest that background retries will resolve it. Tell the subscriber to update the method, use a supported alternative rail, or contact support if they are blocked for another reason.
If update-method completion is low, simplify the correction path before you increase retry frequency. More dunning is unlikely to help if subscribers cannot complete the update flow cleanly.
A known failure mode is updating the wrong payment-method field after a failed attempt. Stripe warns that updates must be applied to the same field that failed, or retries can keep charging the old method. Before you tune retry cadence, including Smart Retries defaults such as 8 tries within 2 weeks, run a failed invoice through the real customer path. Confirm the next retry targets the newly updated method.
Ops queues should prioritize recoverability and urgency, not pure FIFO. For marketplace platform support, segment by risk profile, payment history, failure reason, retry exhaustion, and churn risk. That helps teams focus effort where recovery is most likely and most valuable.
| Queue lane | What should place an account here | What ops should do |
|---|---|---|
| High-value overdue | Overdue invoice with material value | Prioritize outreach and manual review |
| Recoverable but blocked | Failure cohort with recoverable signals, payment method missing or outdated | Push update-method outreach and monitor the next retry |
| Retry exhausted | All scheduled retries consumed with no resolution | Escalate to retention or alternative payment path |
At minimum, show invoice value, overdue status, failure cohort, and retry status in the queue view. High-value overdue alerts are especially useful when you need to keep ops from spending limited capacity on low-value noise.
When card retries keep failing, offer Virtual Bank Accounts (VBAs) where your invoicing flow supports bank transfers. In Stripe invoicing, unique virtual bank account details can appear on invoice surfaces, and Stripe can auto-reconcile received transfers to the correct invoice.
Treat this as a fallback, not a universal replacement. Bank transfers can support recurring billing, but they still require customer action to keep funds available. Before rollout, verify in a live test that customer-specific bank-transfer instructions are visible and that incoming transfers map back to the correct invoice in ops without manual matching.
You might also find this useful: How to Reduce Involuntary Churn: A Platform Operator Playbook for Payment Failure Recovery.
Not every unpaid account should stay in retry automation. Move hard declines, compliance holds, payout constraints, and tax-document gaps into explicit escalation paths before you mark recovery complete.
| Blocker | What to check | Next path |
|---|---|---|
| No payment method on file or issuer hard decline | Stripe Smart Retries stop condition | Payment-method update or manual escalation instead of timed retries |
| KYC, KYB, and related compliance holds | requirements.currently_due is not empty | Compliance review, not the normal success queue |
| Payout readiness | Is the account eligible for the next payout batch? | Billing restored, payouts pending review |
| Tax-profile readiness | Missing or mismatched tax documentation | Treat as a potential blocker; do not treat collected forms as automatic payout enablement |
Stop auto-retries when the processor says to stop. In Stripe Smart Retries, no payment method on file and issuer hard declines are stop conditions, so route these cases to payment-method update or manual escalation instead of timed retries. Store the decline class, invoice ID, customer ID, and required next action in one case record so support can see why the account exited retry treatment. Keep the internal rule narrow: no auto-retry on processor-classified hard declines until a human or customer action occurs.
Treat KYC, KYB, and related compliance holds as reactivation blockers. For Connect programs, verification requirements can block payment and payout capabilities, and embedded-finance onboarding can require both KYC and KYB checks. If requirements.currently_due is not empty, treat the account as still restricted and send it to compliance review, not the normal success queue. Run this requirement check at recovery-close time, not from stale exports.
Gate Payout batches before any "fully live" message. Recovered billing does not guarantee payout readiness. If payouts are paused, both automatic and manual payouts are blocked, and in-flight payouts can remain pending for up to 10 days. Add a required policy check before queue exit: is the account eligible for the next payout batch? If not, communicate "billing restored, payouts pending review" and log payout status in the same recovery case.
Confirm tax-profile readiness before cross-border reactivation promises. Use W-9 for U.S. TIN collection when information reporting applies, and collect W-8 BEN or W-8BEN-E when requested for foreign beneficial owners or entities. Do not treat collected forms as automatic payout enablement, but do treat missing or mismatched tax documentation as a potential blocker. Keep support guidance precise on Form 1099 handling, including that card and certain third-party network transactions are handled under 1099-K, not 1099-MISC or 1099-NEC, and avoid fixed-threshold claims without tax-year review.
Finish with a standing internal note: when regional handling is uncertain, do not claim uniform outcomes. Compliance, payout, and tax-document requirements vary by market and program.
Related reading: How to Handle Payment Disputes as a Platform Operator.
At close, treat an invoice as recovered only when finance can trace it end to end. If you cannot tie the collection outcome to a Ledger journal entry and settlement evidence, keep it out of reported recovered totals.
A recovered invoice should pass a three-part test: confirmed collection event, posted Ledger journal entry, and traceable settlement record. If any link is missing, classify it as an exception.
For Stripe-based flows, BalanceTransaction is a practical bridge across funds movement and settlement, and it should map to your ledger posting records. Use a consistent key set, such as invoice ID, customer or account ID, payment reference, BalanceTransaction ID, journal ID, and payout or bank reference. That lets finance drill from summary totals to transaction detail.
Set one cutoff rule for both ops and finance. Stripe payout reporting uses a day window of 12:00 am to 11:59 pm; mismatched day boundaries create avoidable reconciliation breaks.
Your monthly recovery-close pack should be auditable without engineering reconstruction from raw events. Include:
Ledger journal postings with posting date and journal referenceAs a practical month-end reality, "Every controller has inevitably survived their share of late nights, endless reconciliations, material variances, and unexplained discrepancies." Your pack should reduce that strain, not add to it.
Review unmatched states before close, not after reporting. Typical cases are payment success with no journal, journal with no linked settlement, failed automatic payout, or manual payout not reconciled to transaction history.
Create alerts for unmatched transactions and assign owners to investigation queues. Hold any invoice without required traceability out of recovered totals until it is resolved. For manual payouts, include explicit reconciliation evidence, since reconciliation responsibility sits with the operator.
If you are formalizing monthly recovery close, use Gruv docs to align webhook events, ledger journals, and payout statuses in one reconciliation runbook.
Treat the next 30 days as a controlled optimization cycle, or use another comparable period that matches your billing cadence. Scale only if recovery rate improves against your baseline without adverse risk signals.
Week 1: validate measurement before changing policy. Confirm recovery rate is measured on failed subscription payment volume recovered after failure, and keep ops and finance on the same date logic from close. Read current-month recovery carefully because it can dip while automatic retries are still open. For decline analysis, compare unique declines and exclude failed retries so retry noise does not distort authorization trends.
Week 2: tune retry sequencing carefully. If you use Stripe Billing Smart Retries, use the documented default of 8 tries within 2 weeks as a starting point, with configurable windows from 1 week to 2 months. If recovered invoices rise but dispute or customer-impact signals also rise, reduce retry aggressiveness and revisit sequencing tradeoffs. Treat hard declines as a hard stop: do not continue auto-retries without a new payment method.
Week 3: tune communications. Adjust message timing, channel order, and the subscriber ask before increasing retry count again. If payment-method-update completion is weak, fix that path first.
Week 4: decide scale or rollback. Compare performance to your own baseline, not headline claims from Membership.io or Slicker unless your method, window, and population match.
Use dispute metrics as a hard-stop check. Dispute activity is used in card-network monitoring, and 0.75% is recognized as excessive. Because disputes can arrive up to 120 days after payment, treat short-term recovery gains as provisional when dispute signals trend upward.
End the cycle with a one-page decision memo that names the owner, KPI targets, unresolved risks, rollback conditions, and next integration milestones.
Make the quarter decision on one principle: treat failed payment recovery as a cross-functional operating process, not a retry setting in Stripe Billing or Chargebee. Start by publishing the ownership map and Step 1 classification taxonomy, then do not launch retries until reconciliation checkpoints pass.
Start small if needed, but do not start blind. Smart Retries can improve timing, and Stripe Billing documents a recommended default of 8 tries within 2 weeks, but retries are only one tactic. A complete recovery flow also needs decline handling, customer action paths, internal escalation for overdue high-value invoices, duplicate-safe event handling, and finance evidence that recovered invoices actually settled.
If you cannot name who owns subscriber state, retry logic, and recovery reporting sign-off, you are not ready to scale. You can still test, but keep scope tight and treat gains as provisional until finance verifies them.
Name decision owners for product behavior, engineering behavior, and finance verification, with explicit handoffs for overdue invoices, high-value escalations, and exception review.
Classify failures by decline code and advice_code into recoverable and non-recoverable paths. Keep the hard stop explicit: if a failure returns a hard decline code, do not keep retrying until there is a new payment method.
Teams usually overestimate readiness here. A retry setting is not enough without a decision table for ambiguous codes, customer-action paths, and payment-rail changes. For example, Chargebee retry behavior can differ by rail: one documented direct-debit configuration caps retries at 2, while Smart Dunning can go up to 12 retries in other cases.
Require one engineering gate and one finance gate before launch.
Engineering gate: replay duplicate webhook deliveries and confirm a repeated event does not create duplicate side effects. Stripe notes webhook endpoints can receive the same event more than once, so handlers and follow-on API calls need idempotency keys and replay-safe logic.
Finance gate: prove a recovered invoice can be traced in payout reconciliation and drilled down to underlying transactions. If a dashboard shows "recovered" but finance cannot tie it to settled activity, do not treat it as closed.
Run a bounded pilot this quarter (for example, 30 days): validate instrumentation and duplicate safety, tune retry sequencing, tune customer update-method paths, then make a scale, hold, or rollback decision. Keep market and program caveats explicit while you run it.
Chargebee supports 30+ gateways across 150+ countries, but gateway support still depends on incorporation country. Do not assume Stripe Billing, Chargebee, or any other setup behaves the same across markets, rails, or integrations. Scale only what remains audit-ready after the pilot. If recovery rises while duplicate risk, support load, or reconciliation exceptions also rise, fix controls first.
Before scaling the playbook across regions, talk to Gruv to confirm market coverage, compliance gates, and rollout constraints for your program.
Involuntary churn is when a customer stops a subscription unintentionally, often because a payment fails rather than because they chose to leave. That makes it a payment-recovery issue, not a product-satisfaction issue. For platforms, the revenue impact can compound because a recurring subscriber can remain lost until recovery succeeds, unlike a single failed one-off payment.
Smart retries are only one part of dunning. A complete setup also needs customer reminders, automation for asynchronous events, and recovery analytics that show what failed and what was recovered. It should also give finance a clear reconciliation path from recovery activity to ledger outcomes and exceptions.
There is no universal retry count that fits every platform. Use a bounded, decline-aware policy: some declines should move to payment-method update flows, while recoverable declines can stay in automated retry lanes. As one documented reference point, Chargebee supports smart dunning with up to 12 retries, but that is an implementation ceiling, not a universal target.
Start with native Stripe Billing when your subscription lifecycle is mostly in Stripe and Smart Retries address your retry-timing needs. Consider evaluating Chargebee, Slicker, or custom orchestration when you need different policy or workflow behavior. Validate integration behavior before rollout, because capabilities vary by integration and setup.
Track failure rate, recovered payment volume, and recovery rate to confirm recovery performance. Pair those with reconciliation checks so finance can tie subledger activity to general-ledger balances and identify out-of-balance exceptions. If those links are unclear, treat reported gains as provisional rather than fully recovered.
Webhooks support asynchronous recovery flows, and Stripe can retry delivery for up to three days in live mode, so handlers must tolerate delayed or repeated events. Idempotency keys help make request retries safe by preventing duplicate side effects; Stripe supports keys up to 255 characters and may prune them after they are at least 24 hours old. Ledger journal controls can support reconciliation between subledger and general ledger so teams can surface and resolve exceptions instead of carrying hidden errors forward.
Yuki writes about banking setups, FX strategy, and payment rails for global freelancers—reducing fees while keeping compliance and cashflow predictable.
Includes 3 external sources outside the trusted-domain allowlist.
Educational content only. Not legal, tax, or financial advice.
The hard part is not calculating a commission. It is proving you can pay the right person, in the right state, over the right rail, and explain every exception at month-end. If you cannot do that cleanly, your launch is not ready, even if the demo makes it look simple.
Step 1: **Treat cross-border e-invoicing as a data operations problem, not a PDF problem.**
Cross-border platform payments still need control-focused training because the operating environment is messy. The Financial Stability Board continues to point to the same core cross-border problems: cost, speed, access, and transparency. Enhancing cross-border payments became a G20 priority in 2020. G20 leaders endorsed targets in 2021 across wholesale, retail, and remittances, but BIS has said the end-2027 timeline is unlikely to be met. Build your team's training for that reality, not for a near-term steady state.