Making subscriptions work internationally. 7 chapters and a final quiz.

Chapter 1. Choosing the instrument, market by market.

An international subscription business is managed on the full cost of each collected charge, not on the headline transaction price. That cost has four components: the unit price of the movement, first-attempt failures, retries, and the returns reserve. The fourth is the one most often forgotten. Yet it varies the most from one market to the next, because it depends on a local rule, not on a negotiable price list.

1  Average charge amount .....................  product data

2  Unit price of the movement ................  PSP or bank price list

3  Success rate on the FIRST attempt .........  demand it from the provider
                                                MARKET BY MARKET. A global
                                                average is useless.

4  Cost of one retry attempt .................  PSP price list + bank reject
                                                fees, where there are any

5  Return window of the rail .................  8 weeks, no reason needed, on
                                                SEPA Direct Debit Core,
                                                13 months if the debit is
                                                disputed as unauthorized
                                                (EPC rulebook);
                                                no cap and no time limit in
                                                the UK (Direct Debit
                                                Guarantee, Pay.UK);
                                                60 calendar days on consumer
                                                ACH (return code R10,
                                                Nacha rules);
                                                none on Pix Automatico
                                                (Banco Central do Brasil)

6  Who can stop the series without telling you
     card ...............  nobody, but the credential dies on its own
     SEPA, Bacs .........  the payer's bank, on the payer's instruction
     PayTo, Pix Automatico,
     UPI AutoPay ........  the payer, self-service

FULL COST OF ONE COLLECTED CHARGE
     = 2
     + (1 - 3) x average number of retries x 4
     + returns reserve applied to 1

The trade-off rarely yields a single instrument. It yields a combination, with an order of presentation. The domestic rail goes first wherever it dominates recurring billing, and cards remain the fallback for payers without a local account. A global program therefore ends up with several rails wired in, each with its own success rate, return window and reserve. The discipline lies in measuring them separately.

Chapter 2. Wiring the card mandate, then proving it holds.

The card mandate appears in no national statute. It is created by an authenticated transaction and then kept alive by a reference. That reference is the only proof of the mandate the issuer ever receives, and it travels in every subsequent authorization: the Transaction ID at Visa, the Trace ID at Mastercard. A program that cannot measure how often it appears in its own authorizations is flying blind.

SELECT
    marche,
    psp,
    COUNT(*)                              AS echeances,
    AVG(reference_chainee IS NOT NULL)    AS part_chainee,
    AVG(indicateur_mit IS NOT NULL)       AS part_marquee,
    AVG(mode_saisie = 10)                 AS part_credential_stocke,
    AVG(approuvee)                        AS taux_acceptation
FROM autorisations
WHERE type_operation = 'echeance_abonnement'
GROUP BY marche, psp;

-- How to read the result
--
-- part_chainee < 1
--     part of the card base has lost its original reference.
--     Most frequent cause: a provider migration.
--
-- part_marquee < part_chainee
--     the reference is stored but not sent. That is an
--     integration defect, not a data defect.
--
-- taux_acceptation gap between chained and unchained rows
--     this figure, in percentage points, is the annual cost of the defect.
--     It is the only argument that unlocks an integration budget.

The acceptance test plan for a card mandate

• Authenticated enrollment CIT: check that the response actually carries the chaining identifier, and that the identifier is saved before anything is returned to the user.
• First charge as an MIT: the reference comes back, the entry mode indicates a stored credential, and the CVV is absent. Its absence is normal.
• A charge with no chaining reference, on purpose: the sandbox must decline it with an authentication-required code, and the alert must fire.
• Amount change: the charge leaves the fixed-amount series. The flag must change, or the issuer will read something other than what you think you are sending.
• Frequency change: switching from monthly to annual opens a new series. The original reference does not cover it.
• Retry after a decline: it carries a separate MIT type, resubmission, and the amount of the original charge.
• Reissued card: simulate the update from the scheme's updater service, then replay a charge on the refreshed credential.
• Cancellation: the revocation of the stored credential must be verifiable, and the test must confirm that no charge goes out after the effective date.

That leaves maintenance of the card base. Scheme updater services, such as Visa Account Updater or Mastercard's Automatic Billing Updater, refresh a reissued credential. Network tokens issued under the EMVCo specification survive card reissuance. These tools must be purchased; they do not come with storage. None of them recovers a card the customer has deliberately removed. Their coverage varies by market, so a refresh rate observed in one country cannot be extrapolated to others.

Chapter 3. Opening a local direct debit rail.

A direct debit rail is not opened with an API key but with an application. A bank, an operator or a central bank agrees, or refuses, to let you pull funds from your customers' accounts. The review takes weeks, and it must start while the engineering team is building, never afterward. A plan that schedules the rail opening after technical acceptance testing pushes go-live back by a full quarter.

Shared goal: debit the payer's account on the 5th of the month

SEPA Direct Debit Core
  pre-notification ........  14 calendar days before the debit by default;
                             can be shortened by agreement with the payer
  pain.008 submission .....  no later than D-1 (business day), Core and B2B
  interbank return ........  up to 5 business days after settlement in Core,
                             2 business days in B2B
  refund right ............  8 weeks with no reason, 13 months if unauthorized

Direct Debit on Bacs
  advance notice ..........  10 business days by default, set in the
                             sponsorship agreement
  file submission .........  day 1 of a 3-business-day cycle, so
                             2 business days before the debit date
  unpaid items ............  ARUDD file, on settlement day
  guarantee ...............  Direct Debit Guarantee, no cap and no time limit

ACH debit, SEC codes PPD and WEB
  advance notice ..........  10 calendar days before any debit whose
                             amount differs from the previous one
  account validation ......  mandatory on the first WEB debit
  unauthorized return .....  code R10, 60 calendar days after settlement
  monitoring ..............  Nacha threshold of 0.5% unauthorized returns

OPERATIONAL CONSEQUENCE
  The billing date is not the debit date. The billing engine must
  compute a submission date per rail and per market, then work the
  advance notice back from it.

• A mandate has a shelf life. In SEPA, it lapses after 36 months without a debit. Reusing it after that exposes you to a reject for an invalid mandate.
• The return file is not optional. ARUDD, ADDACS and their equivalents must be processed automatically, or the series keeps running on a dead mandate.
• Keep the advance notice. On Bacs, without proof that it was sent, you lose the indemnity claim without any review of the merits.
• The local calendar comes first. Betalingsservice imposes a monthly cycle: you don't choose the billing date, you live with it.
• European B2B has a condition precedent. If the debtor has not registered the mandate with its bank, the first charge is rejected.
• In the US, your counterparty is your bank. There is no standardized creditor identifier and no sequence control: the originating bank carries the risk and sets its own limits.

One last difference sets US ACH apart from every other rail in this chapter. There is no mandate in the European sense: no standardized creditor identifier, no reference carried in the message, no sequence control. What takes its place is an authorization whose form depends on the channel, declared by a three-letter code. The risk sits with the bank that originates the entry into the network.

Chapter 4. Enrolling a native mandate: e-NACH, UPI AutoPay, PayTo, Pix Automático.

On these rails, the mandate no longer lives in your files. It lives in the payer's banking app, where the payer can view, suspend and revoke it in three taps. Settlement is instant, so is collection, and success rates are higher as a result. In exchange, you lose control of the exit channel, which changes how the whole operation runs.

MANDATE OBJECT - the minimum to store

  mandate_id ............  ID returned by the operator;
                           never regenerated, never recomputed
  rail ..................  upi_autopay | enach | payto | pix_automatico
  status ................  pending | active | suspended | revoked | expired
  cap ...................  maximum amount per charge, in local currency
  frequency .............  declared at authorization; changing it
                           requires a new authorization on several rails
  valid_until ...........  end date; open-ended authorizations are not
                           available everywhere
  last_charge ...........  date, amount, outcome
  status_source .........  operator event, or inferred after a reject
                           (log the difference: it matters in a dispute)

EVENTS TO PROCESS, OR YOU BILL INTO THE VOID

  mandate.active           -> open the service
  mandate.suspended        -> stop presenting, keep the contract
  mandate.revoked          -> stop the series AND trigger the product-side
                              exit flow
  mandate.cap_changed      -> recompute the charge BEFORE presenting
  charge.rejected          -> classify the reason before any retry

CLASSIC TRAP
  A revoked mandate is not a contract cancellation. Should the service
  be cut off? Does the debt keep running? Settle both questions once,
  in the terms and conditions, not case by case.

Pix Automático is the best-documented case of this generation. The payment instruction goes out 2 to 10 days before the scheduled settlement date. Settlement runs in two mandatory windows: midnight to 8 a.m., then 6 p.m. to 9 p.m., Brasília time. A failure triggers a new attempt the same day, preceded by a notification asking the payer to top up their account, and retries can continue for up to seven days if the authorization allows it.

• Ask the local provider for its event catalog, and check that it exposes suspension, not just revocation.
• Ask for the propagation delay between the payer's action and the event you receive. It determines how many charges go out into the void.
• Check how the cap can be changed: some rails allow it without a new authorization, others do not.
• Test the payee name as it appears in the payer's banking app. It is the leading cause of drop-off at enrollment.
• In Malaysia, the direct debit component is called DuitNow AutoDebit, operated by Payments Network Malaysia under Bank Negara Malaysia supervision. DuitNow Transfer and FPX are payer-initiated and are no substitute for a mandate.
• In the UK, Open Banking Limited's Variable Recurring Payments are live for sweeping. The commercial use case has not yet been rolled out at scale.

Chapter 5. Running dunning across multiple markets.

A failed charge falls into one of three families, and confusing them wrecks a retry policy. If the instrument is dead, no attempt will ever succeed. If it is alive but funds are short, a later attempt stands a chance. If the flag is wrong, the failure comes from the integration, not the payment. Retrying the first family costs money and draws the schemes' attention.

input 1: reason family    dead_instrument | insufficient_funds | flagging
input 2: rail             card | sepa | bacs | ach | native
input 3: market           local payday calendar

if family = dead_instrument:
    0 attempts.
    Repair first: credential update through the scheme's updater service,
    new bank details, new mandate. Then, and only then,
    present again.

if family = flagging:
    0 attempts.
    An "authentication required" decline is never replayed: no cardholder
    is in session. Fix the integration, then restart the series.

if family = insufficient_funds:
    n attempts, with n strictly below the scheme cap,
    spaced out and timed to a local payday.
    Documented example: in Brazil, wages are due no later than the
    fifth business day of the following month
    (Consolidacao das Leis do Trabalho, art. 459, par. 1).

in all cases:
    notify the payer before retrying;
    log the decision AND its reason;
    stop as soon as a return file reports a cancellation.

Measuring a retry policy

• Publish two rates, never one. The first-attempt rate measures the quality of the instrument and the flagging. The post-retry rate measures the policy. The gap between them measures what the policy earns.
• Break it down by market, rail and provider. A global average hides exactly the market that is bleeding.
• Separate explicit refusals from technical rejects. In India, the payer can refuse a charge after reading the pre-notification, 24 hours before the debit. That is not a funds problem.
• Count the cost of attempts, bank reject fees included, and subtract it from the amount recovered. An aggressive policy can post a good rate and still destroy margin.
• Track the lag between the return file and stopping the series. Every day of lag produces a charge into the void, then a dispute.

A retry model imported from Europe or the US is built around reject codes. India's framework moves the breaking point: part of the failure happens not at the debit but the day before, when the payer reads the notification. The customer is not short of funds. The customer chooses to refuse, and the remedy is a clearer message, never another attempt.

Chapter 6. Building a single exit flow.

Cancellation has changed category. It used to be a customer service matter; it is now a compliance and engineering matter. Several markets require that stopping be as easy as signing up, through the same channel. The laws converge on that principle, and diverge on labels, deadlines and evidence, which differ from one statute to the next.

• One flow, aligned with the strictest regime, with mandatory local wording layered on top.
• One effective date, pushed to the billing engine and the collection engine in the same transaction.
• A retained enrollment log: timestamp, IP address, version of the terms accepted. It is the document missing from most lost dispute cases.
• Shutdown documented in both directions: a cancellation that stops the series, and a mandate revocation that triggers a product decision.
• One metric: the time between the cancellation request and the actual end of debits, measured by market.

This table yields two lessons. First, recent statutes target the flow, not the contract: a button, a confirmation page, an effective date. Second, the law and the plumbing are out of step. Canceling a contract never automatically shuts down a payment mandate, and revoking a mandate cancels no contract. The two breaks therefore call for two treatments, triggered by two separate events.

Chapter 7. VAT on digital services, from the collections side.

Indirect tax is not a month-end issue for the accounting team; it determines the amount debited. A subscription sold at the same pre-tax price produces different charges depending on the customer's country, and that variation runs through the whole chain: card flagging, pre-notification, mandate cap. Treating it as payment data prevents rejects that nothing on the product side can explain.

• Part of the proof of location comes from the payment chain. Implementing Regulation (EU) No 282/2011 accepts, among other things, the billing address, the IP address, the customer's bank details, the mobile country code of the SIM card and the location of the landline.
• Two non-contradictory pieces of evidence are required. Below €100,000 in annual sales of these services, one is enough (Implementing Regulation (EU) 2017/2459, in force since January 1, 2019).
• The card's issuing country is tax data. Store it with the subscription, not just with the transaction.
• In intra-EU B2B, the customer accounts for the tax under the reverse charge, provided its VAT number has been validated. A failed validation turns a tax-exclusive invoice into a VAT liability.
• The price shown to consumers is an all-in price, tax included (Directive 2011/83/EU, art. 6(1)(e)). The amount debited therefore follows the local rate, not the reference price.
• The “VAT in the Digital Age” package was adopted through Directive (EU) 2025/516 of March 11, 2025, with milestones phased in from January 1, 2027, and then July 1, 2028.

Same offer, same pre-tax price of 20.00 in local currency

  Market A, standard rate 20%
    pre-tax base ...........  20.00
    displayed price ........  24.00   (all-in price, tax included)
    amount debited .........  24.00

  Market B, standard rate 19%
    pre-tax base ...........  20.00
    displayed price ........  23.80
    amount debited .........  23.80

TWO CONSEQUENCES FOR COLLECTION

  1. The amount debited differs from one market to another for the same offer.
     A card series flagged "recurring" at a fixed amount must be declared
     PER MARKET. A global declaration misleads the network.

  2. A rate increase changes the amount in the middle of a series.
     - Card: the fixed-amount flag no longer holds; it must be reclassified.
     - SEPA, Bacs: the pre-notification must show the NEW amount.
     - ACH: a debit whose amount differs from the previous one requires
       10 calendar days of advance notice.
     - PayTo, UPI AutoPay, Pix Automatico: the mandate cap must have
       been set higher. Otherwise the charge is rejected.

That leaves the merchant of record trade-off, in which a third party becomes the official seller and handles tax compliance for you. The gain is real in markets you don't want to take on yourself. In exchange, the statement descriptor becomes theirs, the disputes belong to them and the mandate is signed in their name, so the portability of your subscriber base disappears with the contract.