To set up auto-billing for monthly retainers, choose the collection path first: auto-charge a stored payment method or send recurring invoices. Then align the contract, payment rail, technical flow, failure handling, and finance controls to that choice. Before launch, segment customers by procurement path, validate ACH or SEPA by market, test webhook and idempotency behavior, and confirm dunning and reconciliation ownership.
Start with the collection path, not the interface. For monthly retainers, you can either auto-charge a stored payment method or send an invoice first. That choice sets expectations for contracts, failure handling, and finance operations.
Use this guide as an execution sequence: commercial terms, payment rail, technical flow, failure handling, then close controls. Two definitions keep the scope clear. Payment Links let you accept payments, including subscriptions, without building a separate site or app. Automatic charging means your setup attempts to pay an invoice with a payment method already on file. They are related, but operationally they are different.
Recurring billing has two valid starting paths: auto-charge or invoice-first collection. Choose based on how your customers actually pay and approve purchases.
The tradeoff is not just conversion. Manual methods add tracking and reconciliation work, so decide early which customer segments you can auto-charge and which require recurring invoices before you build.
Treat ACH and SEPA rails as market-specific, not interchangeable defaults. ACH Direct Debit is for US bank accounts. SEPA eligibility depends on the SEPA scheme country and territory scope, so validate target payer markets against the current EPC list instead of using a generic "Europe" rule.
Before you build, capture your target payer markets, preferred rails by segment, and whether each flow requires card-on-file or bank-based collection.
Verification requirements vary by account context, including location, business type, capabilities, and country-level configuration for enabling charges or payouts. Run a market-by-market verification check, not just a product signoff.
Processor verification does not replace your own legal KYC or verification obligations. Failed-payment behavior also differs by method: default retries are not uniform across rails, and failed non-card methods and Direct Debit payments are not automatically retried by default except ACH Direct Debit. Confirm you can consume invoice.payment_failed and route it into retries, status changes, and customer notifications before enabling live monthly charges.
The rest of this guide follows that order so each decision is made once, with fewer downstream surprises. You might also find this useful: SEPA Payments for Platforms: Direct Debit Instant Transfer and Recurring Billing.
Do not turn on monthly charging until the commercial baseline, procurement path, and operational ownership are explicit. Many avoidable issues start with unclear terms, a buying flow that does not match the billing motion, or payment-state handling that nobody owns.
Work from the documents and terms your teams will actually use: retainer agreement, statement of work (or similar scope document), billing day, and any rollover terms if they apply. The goal is alignment, not perfect drafting, so everyone is working from the same billing promise and the same handling for unused time, credits, or capacity.
Use a simple test: from signed docs alone, can someone outside the deal team see the expected amount, charge timing, and what changes require an amendment? If not, fix that before launch.
Decide upfront which accounts will run through MSA + PO and which can accept self-serve terms. An MSA sets governing terms for current and future work, and procurement-led buying can require linked service detail and pricing artifacts. A PO is the buyer's formal purchase authorization.
Do not force one path across all segments. If PO-backed approval is required, design for that path early instead of finding out later that enterprise AP may not process your default flow.
Assign clear owners for flow design, payment-event handling, and finance controls before build starts. Engineering should own webhook endpoint behavior and idempotency key handling so retrying POST requests does not create duplicate operations.
Set the key rules before launch: Stripe idempotency keys are up to 255 characters, and keys can be removed after they are at least 24 hours old. Then verify behavior in practice. Test webhook handling locally, confirm duplicate retries return the same result, and confirm finance can trace outcomes into ledger records.
Treat launch readiness as operational proof, not a successful demo charge. Require one end-to-end payment through staging or pilot, plus evidence of journal posting in your accounting flow and a failed-payment path that routes correctly from event receipt through follow-up.
If automated retries are enabled, test them too. Retry policies can recover failed recurring collections, but you still need replay-safe side effects and accounting traceability that ties internal journal or general ledger records to external payment statements.
For a step-by-step walkthrough, see How to Use Stripe Payment Links for Easy Invoicing.
Pick the model that matches how service is actually consumed, then make the collection method match the contract. When monthly scope and amount stay stable, fixed recurring charges are often simpler to run. When consumption moves materially, a baseline plus overage can be cleaner than forcing everything into one flat fee.
Start with one question: what event creates the charge?
| Model | Billing trigger | Overage handling | Clarity risk if terms are vague | Client fit |
|---|---|---|---|---|
| Fixed monthly retainer | Same amount each billing cycle | Usually none, or handled separately | Can center on whether included work is clearly defined | Buyers purchasing stable access, reserved capacity, or a consistent package |
| Variable retainer | Bill after measured usage or consumption | Built in, often per-unit above included amount | Can center on unit definitions, records, and timing clarity | Buyers with month-to-month demand swings who accept usage-based settlement |
| Hybrid baseline plus overage | Recurring base charge plus usage above included units | Per-unit overage above included units, billed in arrears | Can center on whether units, caps, and approvals are explicit | Buyers who want predictable baseline spend with room for variable demand |
Use fixed logic when you can explain the monthly fee clearly and consistently. Use hybrid logic when variable demand is real and you need explicit overage rules.
Use fixed pricing when the amount is a set figure at regular intervals. That is usually the cleanest fit for retainers with a consistent amount. For collection, you can use automatic charging from a stored payment method or recurring invoices/manual payments, depending on the contract and buyer process.
Checkpoint: someone outside the deal team should be able to read the signed terms and predict the next charge amount and timing without asking for clarification.
If usage changes materially, keep the committed base separate from variable consumption. Flat recurring fees and overage mechanics are different billing models, and usage-billed components are typically settled in arrears, so the timing of extra charges should be explicit.
Before launch, define the billed unit, included threshold, overage rate, and the usage record you will rely on if the charge is questioned.
In the retainer agreement and scope letter, state in plain language:
Clear recurring terms help cardholder clarity and can reduce dispute friction. Visa and Mastercard both introduced subscription and recurring policy updates on 18 April 2020 and September 22, 2022.
Mixed contracts need separation before you automate them. Keep a fixed retainer separate from any activity-based component so you can explain each charge cleanly. Let the collection method follow contract reality, for example automatic charging for some accounts and invoice-first flows for others.
We covered this in detail in Recurring Billing for Marketplaces: How to Charge Buyers and Pay Sellers on the Same Cycle.
Choose the rail based on two things: your buyer's approval flow and your team's tolerance for delayed outcomes after the invoice date. Use card on file when the contract and billing setup allow stored-method charging. Use ACH or SEPA Direct Debit when you need bank-debit collection with invoice-compatible operations.
| Criteria | Payment card on file | ACH Direct Debit | SEPA Direct Debit |
|---|---|---|---|
| Collection signal and timing | Used for stored-method recurring charging. Keep in mind dispute events can still reverse funds after collection. | Delayed notification method. Stripe documents up to 4 business days for success or failure acknowledgement, and a payment typically takes 4 business days to arrive. | Delayed notification method. Stripe documents funds are not immediately available, and a payment typically takes 5 business days to arrive. |
| Failure and dispute exposure | Cardholder disputes can immediately reverse payment when an issuer creates the dispute. | Not a guaranteed payment method, so failed payments and disputes are part of normal operations. | Requires customer mandate acceptance. Stripe summarizes an 8-week dispute window, and up to 13 months for unauthorized debits in some cases. |
| Buyer and process fit | Fit when the buyer can be auto-charged using a saved payment method. | Fit when the payment flow is U.S. bank debit and invoice-led collection. | Fit for SEPA-region payers (ECB: 41 European countries). In Stripe's documented context, the per-transaction limit is 10,000 EUR. |
| What changes operationally | You need clear handling for failed attempts, customer notices, and dispute queues. | You need webhook-driven monitoring because outcomes are asynchronous. Retry behavior is method-specific, and Stripe notes defaults differ for non-card methods and Direct Debit. | Same delayed-notification pattern as ACH, plus mandate capture checks and dispute-handling queues. Customer messaging should say collection is pending, not final on day one. |
The core tradeoff is operational certainty. ACH and SEPA Direct Debit can work well for retainers, but both require delayed-outcome handling. Cards can work for stored-method charging, but chargeback exposure remains.
If an account requires PO, MSA, or AP invoice approval before settlement, ACH or SEPA Direct Debit is often the safer starting point for an invoice-compatible flow. If an account accepts stored credentials for automatic charging, card on file can be the starting point, with a bank option for procurement exceptions or failed card collection.
Checkpoint before go-live: your finance team should be able to say which accounts can be auto-charged and which must stay invoice-first. If that rule is unclear, exceptions can grow quickly.
Virtual Accounts fit when buyers want invoice-led bank transfer collection instead of direct-debit authorization. You provide a customer-specific virtual bank account number, which supports matching while avoiding exposure of your real account details.
The tradeoff is payer action. Bank transfers can support recurring billing, but the customer still needs to initiate each payment. Plan for unmatched-transfer exceptions too. If auto-matching fails, transfers can remain in customer balance until someone manually clears them.
Before you standardize on a rail, test one full path per segment: payment attempt, webhook notification, customer message, and invoice matching. For SEPA, confirm mandate acceptance records are retrievable. For transfer-led collection, assign clear ownership for unmatched deposits on day one. Related reading: Non-Profit Membership Billing for Recurring Donations and Member Tiers.
After you choose the rail, treat billing motion as a segment decision, not a company-wide default. In many mixed books, run both in parallel. Use charge_automatically where stored-method charging is approved and buying is low-friction, and use send_invoice where procurement, PO review, or bank-transfer collection drives payment.
In Stripe, collection_method is the decision lever: charge_automatically auto-charges the default payment method for each billing-period invoice, while send_invoice creates an invoice that is paid manually. In practice, procurement behavior often decides the mode.
| Segment | Typical signals | Recommended collection_method | Why it fits |
|---|---|---|---|
| Self-serve or low-touch SMB | Card accepted, no PO, standard online acceptance, broad signup flow | charge_automatically | Matches the buying motion. Payment Links are broadly shareable, which fits this audience. |
| Mid-market with named account owner | Buyer can save a method, limited procurement review | Usually charge_automatically, with invoice fallback | Keeps collection more predictable when stored-method charging is approved, with invoicing for exceptions. |
| Enterprise AP-led buyer | PO, bank-transfer preference, invoice approval, three-way matching | send_invoice | AP teams often require invoice review and tighter payment matching. Some methods, such as bank transfers, only support invoice-based collection. |
Checkpoint: sales or finance should be able to classify an account before the first invoice is created. If classification is deferred, exceptions grow quickly.
When buyer behavior splits, so should your billing motion. Use auto-billing for self-serve tiers and recurring invoices for AP-driven accounts. Stripe positions invoices as customer-specific collection, while Payment Links can be used by anyone with the link, which maps cleanly to this split.
Auto-billing reduces follow-up work for self-serve plans. Recurring invoices can be lower-friction for buyers that require PO data, AP review, or three-way matching against PO and delivery evidence.
Manual invoicing increases follow-up workload and lowers cash-timing certainty. Stripe finalizes subscription invoices immediately with charge_automatically, but one hour later with send_invoice. Reminder timing can run from 10 days before the due date to 60 days after, with up to three reminders.
Operationally, "invoice sent" is not the same as "cash collected," especially with net terms such as due in 30 days or bank-transfer flows that still need payment matching.
A practical path is invoice-first, then auto-charge once approval conditions are clear. That means stored-method charging is approved, a valid default payment method is on file, and the buyer no longer requires every cycle to pass through PO or AP approval.
Then switch subscription collection_method from send_invoice to charge_automatically. Verify the next generated invoice uses the new mode. Stripe applies the change to subsequently created subscription invoices, not the currently open one.
If you want a deeper dive, read How to use 'Stripe Invoicing' to set up a recurring retainer with a client. Need a concrete reference for splitting auto-charge and invoice-led segments with safe retries? Review the Gruv docs.
Define terms before you launch billing. Avoidable disputes often start when scope, rollover, or failure rules are not written clearly.
Your minimum pack should answer relationship, scope, and billing questions separately rather than through one vague document. Use a Retainer agreement for the commercial promise and an MSA for standing relationship terms across work. Then use a project-level Scope letter or SOW-equivalent for specific scope, timeline, and cost. At minimum, include:
Make billing cadence explicit: billing day, prepay vs arrears, renewal behavior, and authorized payment method. Make rollover explicit: what carries forward, what expires, any carryover cap, and whether unused value becomes credit or lapses.
Readiness check: finance, sales, and delivery should all point to the same clause for scope, monthly amount, billing date, and unused-capacity treatment. If any answer lives only in email, the pack is not ready.
For self-serve recurring acceptance, show material terms clearly at consent. For covered recurring or negative-option offers, federal rules require clear and conspicuous disclosure of material terms. The FTC final Negative Option Rule is effective January 14, 2025, with May 14, 2025 compliance dates for key sections. Applicability depends on program structure and jurisdiction, so treat this as a drafting baseline and review consumer-facing flows closely.
Your failure policy has to be specific enough to configure in billing systems. Define the grace window, service behavior during non-payment, outreach owner, and escalation trigger during Dunning.
Be explicit on three points:
Do not promise one retry pattern across all rails unless it is true. Some methods can skip retries and move directly to dunning end actions, while card flows can run automated retries, including configurations such as up to 8 retries within 2 months. If you support multiple rails, write rail-specific failure terms.
Verification check: test one failed card charge and one method with a different retry path. Confirm customer messaging, escalation owner, and service-status changes match the contract language.
For procurement-led buyers, include a PO rule in the MSA or ordering terms and tie each scope letter or SOW to the active PO. State what happens if a PO expires mid-term, who requests amendments, whether work pauses without a valid PO, and whether invoicing is allowed on an expired blanket PO.
Do not assume universal PO behavior. Some setups block invoicing after expiry, while others allow invoicing on expired blanket POs by configuration. Expiration date changes can also require buyer-side updates, so amendment ownership must be explicit.
Go-live check: confirm PO expiry behavior in the buyer's live AP or procurement system and name the amendment owner. One failure path is simple: delivery continues, the PO lapses, invoicing is blocked or rejected, and payment turns into an off-contract dispute.
This pairs well with our guide on Shopify Subscription Integration for Recurring Billing Without Migration Pain.
Build this flow so one economic event produces one internal outcome. In retainer flows that use payment links, plan for state and ledger mismatches, plus duplicate internal postings after retries and replays.
Choose one handoff object and keep it consistent. In a Stripe invoice-led flow, invoices start as draft, finalization sets status=open, and that finalization creates a payable hosted URL. If you use a reusable payment link, each open creates a checkout session, so your internal attempt record still needs to bind customer, billing period, and attempt.
Use one canonical sequence:
Keep steps 5 through 8 separate in your system. Webhooks are the async signal, not your internal ledger.
Stripe-specific timing checkpoint: Stripe waits 1 hour after successful invoice.created webhook responses before attempting automatic collection. If success is not received, it can finalize or send after 72 hours, and retries can continue for up to 3 days. Validate your endpoint behavior early so billing is not delayed silently.
Verification point: in one test invoice, confirm draft -> open, the hosted payment URL exists, and your internal attempt is linked to the provider object ID.
Keep invoice lifecycle state separate from payment-attempt state. Allow only approved signals to move a transition.
| Internal state | Provider signal | Next action |
|---|---|---|
invoice_draft | invoice created | Store provider invoice ID; not payable yet |
checkout_available | invoice finalized or status=open | Save hosted URL; allow payment or auto collection |
payment_pending | payment in progress or async confirmation pending | Hold ledger posting and customer-access changes |
paid_confirmed | status=paid or equivalent paid webhook | Mark settled, post journal, send confirmation |
payment_failed | provider reports payment failure | Route to retry or dunning; do not post paid journal |
closed_no_collect | void or uncollectible outcome | Stop collection path; update finance and customer status |
Verification point: test each terminal path you support, at minimum paid, uncollectible, and void.
Idempotency needs three controls:
Example key shapes:
inv_{invoiceId}_v1inv_{invoiceId}_attempt_2event_idKeep keys compact. Adyen caps idempotency keys at 64 characters.
If a timeout happens after provider acceptance, repeating the same key can return the same result, including a 500. Before rotating keys, check whether the object already exists via your stored provider ID or metadata when available. Before mutating state, verify webhook authenticity. Then store the raw event, return a 2xx HTTP status code where required, and process asynchronously.
Before go-live, require these checkpoints in staging and pilot:
If any checkpoint is missing, the flow is incomplete. Final go-live check: run one successful payment, one failed payment, and one duplicate webhook replay, then confirm each was received and posted economically once internally.
Related: The Best Payment Gateways for SaaS Businesses.
Failure handling should move quickly into a defined recovery path without creating churn, duplicate postings, or month-end close noise.
Set this in advance for each segment and rail: retry timing, customer channel, and owner. Dunning is failed-payment recovery through retries plus reminders, so your policy should also define manual escalation ownership and what happens after the final retry fails.
For transient issues, keep retries available. Soft declines are temporary, and many recurring failures are recoverable. Platform examples show the level of specificity you need:
Set a clear tier rule up front: decide which accounts get human outreach before access restrictions, and which stay on a strict automated path.
Do not send every failure into the same retry loop.
| Failure type | What to do |
|---|---|
| Soft decline | Retry per policy. |
| Expired card | Do not keep retrying the same card. Collect updated details or rely on card-updater coverage. |
| Hard decline or missing payment method | Route out of automatic retries into customer action or manual handling. |
| SEPA mandate canceled or inactive | Treat as an authorization issue. Collect a valid mandate path before continuing. |
| ACH return or rejection | Capture the exact return code, range R01 to R85, in your ops workflow so teams can resolve correctly. |
Verification point: for each rail you support, test one soft failure and one non-retryable failure, then confirm the correct branch fired, the correct notice was sent, and no duplicate paid state was posted.
The failures that create the most cleanup are often the quiet ones. Track these explicitly:
Keep the idempotency and replay controls from your core flow active during incident handling.
Close incidents only when payment reality and accounting reality match. Use an evidence pack with:
Do not mark the incident resolved until all required records line up.
Finance and ops are audit ready when your team can prove what happened without rebuilding the story by hand. Define matching checks before launch so invoice states, cash movement, refunds or returns, and Ledger journals stay aligned through routine review and month-end close.
Run a daily check that ties billing status to cash and journals. Confirm paid invoices have a settlement trail, failed or canceled items did not leave paid journals, and refunds or returns have matching reversal entries in your books.
Use record-level traceability as the pass or fail test: invoice ID -> provider payment ID -> settlement or payout reference -> journal entry ID, and back again. If that chain is slow or broken, your control is weak.
Use provider reports designed for close work. Stripe's Bank reconciliation report is built around monthly activity and cash impact. The Payout reconciliation report helps tie bank payouts back to underlying transaction batches grouped by reporting category.
If you use manual payouts, add an explicit close control. Stripe cannot infer which transactions are included when you set payout timing and amount, so your team must match those payouts directly.
Document exception queues as named investigation stages with an owner, an entry rule, and a response target that matches your close calendar. Start with queues such as:
With Virtual Accounts and VBANs, review should start from incoming transfer attribution, not only payment-attempt status. VBANs support automated matching and help avoid exposing real account details, but virtual accounts do not hold funds directly. Transactions post to the linked physical account.
Treat unreconciled transfers as a dedicated queue. If a transfer is not auto-matched, it can remain in customer balance until manually cleared.
Dashboard visibility is not enough. Finance teams need downloadable records, and finance systems may need programmatic report access. Standardize an export pack that includes:
When this is standardized from day one, month-end becomes controlled review and exception handling, not reconstruction.
Treat compliance and tax as explicit capability gates tied to money movement, not background admin. If you hide them inside a generic "account active" status, you risk either allowing the wrong party to collect or pay out, or freezing good accounts with no clear recovery path.
Map your gates at three separate moments: customer collection, seller or contractor payout, and ongoing account capability. In platform models, KYC can be a hard gate before connected accounts can accept payments and send payouts, and unmet requirements can restrict capabilities. Some providers apply this directly by allowing or blocking actions based on verification outcomes.
Assign status by money action, not just by profile. Labels like "can collect," "can receive payouts," and "restricted pending review" are more useful than one broad onboarding state. Where business verification applies, keep person checks and business checks separate so an incomplete business file is not confused with a failed individual identity check.
Verification checkpoint: For each account, your ops view or export should show what requirement is outstanding, which capability it affects, and what document or field clears it. If that still requires manual dashboard reading, the control is not launch-ready.
Do not treat verification as one-and-done. KYC requirements can change over time as regulators, card networks, and financial institutions update requirements, so build for re-verification notices and requirement updates.
Request tax forms only where your reporting or withholding path actually needs them, and make the operational consequence of a missing form explicit. Asking every user for every form on day one can add friction without clear control gains.
For U.S. persons, Form W-9 is used to request the taxpayer identification number. For foreign beneficial owners, Form W-8BEN or W-8BEN-E is used to establish foreign status in U.S. withholding and reporting contexts. If you pay independent contractors, Form 1099-NEC may be required. Form 1099-K is tied to payment-card and third-party network transactions, so it generally serves a different reporting lane than 1099-NEC.
Design an evidence pack your team can act on: form type, collection date, legal name, taxpayer status, and the account or payee ID the form supports.
Verification checkpoint: Where your policy requires W-9 or W-8 collection, test a payout hold triggered by a missing form and confirm the account owner sees the exact missing item, not a generic "compliance review" error.
Flag VAT and foreign-account reporting during design, not after go-live. If you bill EU businesses cross-border, add VAT-number validation to onboarding or invoice setup. VIES is used to check whether a business is VAT-registered for cross-border trade, but it is a search engine, not a database, so log the validation result and timestamp. Also account for the UK exception: as of 01/01/2021, UK (GB) VAT-number validation through VIES ceased.
FBAR is a separate reporting flag that can affect program design when U.S. persons have qualifying foreign financial accounts. Reporting is filed on FinCEN Form 114, and the IRS trigger is aggregate foreign account value exceeding $10,000 at any time during the calendar year reported. This obligation is based on foreign-account reporting criteria, not whether the account produced taxable income.
If your payout design uses foreign financial accounts, treat that as a tax and treasury review gate before launch. The failure mode is finding the reporting consequence only after finance has already routed funds through those accounts.
Common costly failures in these retainer setups usually come from four preventable gaps: duplicate processing, unclear billing authority, ownerless failed collections, and weak close controls.
Treat every retry as the same intent, not a new operation. Use Idempotency keys on create and retry requests so timeouts or resubmits do not accidentally duplicate operations.
Apply the same logic to webhooks: duplicate deliveries can happen, so store processed event IDs and skip repeats. Verification checkpoint: replay one webhook event twice in staging and confirm the second delivery causes no additional state change.
Make billing authority explicit before scale. If terms are documented across agreements and scope documents, ensure cadence, charge basis, continuation or renewal logic, failed-payment handling, and change approval are clear.
For consumer negative-option plans, material terms must be clearly disclosed. Where bank debits apply, validate the authorization artifact itself: U.S. consumer preauthorized EFTs require signed or similarly authenticated authorization plus a copy to the consumer, and SEPA Direct Debit requires a signed payer mandate.
A dunning flow without clear ownership becomes a silent write-off queue. Set owner and escalation rules by value and account type: route overdue high-value retainers to human follow-up, and keep lower-touch tiers on automated retries and notifications.
Automation can retry failed recurring invoices and subscriptions, but example settings such as "up to 8 times within 2 months" are not universal defaults. Verification checkpoint: force a failed payment in pilot and confirm the correct internal team is notified for overdue high-value invoices.
Before scaling, verify end-to-end matching is reliable. Validate transaction-to-payout-to-ledger traceability first. Automatic payouts can help preserve transaction-to-payout linkage and simplify reporting and reconciliation.
Run this in staging and a small pilot across successful collections, failed collections, refunds or returns, and duplicate-event replays. If finance cannot trace a payment attempt through status, settlement, payout linkage, and accounting impact, fix the control before broader rollout.
Need the full breakdown? Read Subscription Billing for eCommerce DTC Brands Adding Recurring Revenue to Physical Products.
Execution quality is the launch standard for monthly retainers, not feature choice. Before go-live, make sure commercial terms, collection method, event handling, and finance controls all match.
Confirm signed commercial artifacts. Verify each live account against signed artifacts (for example, a Retainer agreement, Scope letter, billing cadence terms, and Rollover policy, where applicable) so the written promise matches what will be charged and when.
Approve segment rules for Auto-billing vs Recurring invoices. Treat this as policy, not case-by-case judgment. Auto-billing charges a saved payment method on file, while Recurring invoices are generated and sent on a fixed schedule and can allow an adjustable payment window instead of immediate collection.
Validate rail coverage and real behavior. Check Payment card on file, ACH, and SEPA Direct Debit for the markets and account capabilities you support. Test delayed outcomes for bank-debit rails: ACH Direct Debit can take up to 4 business days for success or failure acknowledgement, and in this Stripe context SEPA Direct Debit typically takes 5 business days to arrive and has a 10,000 EUR each transaction limit.
Test Webhook events, Idempotency keys, and state transitions end to end. Confirm the full chain works: event received, internal state updated, journal posted, and customer notification sent where applicable. Use Idempotency keys on create and retry calls and ensure webhook consumers are replay-safe.
Pass go-live matching checks tied to Ledger journals. Match processor transaction records to accounting records in the general ledger across successful payments, failures, and refund or return paths. Validate there are no orphan settlements or duplicate postings.
Finalize Dunning ownership and recovery evidence. Assign ownership for failed-payment messaging, high-value follow-up, and incident-closure evidence. Stripe's documented Smart Retry default of 8 tries within 2 weeks is a starting point, then tune by segment.
Final gate: no launch until commercial artifacts are approved, segment rules are approved, rails are validated, asynchronous events are replay-safe, matching passes, and failed-payment ownership is clear. Payment Links can speed subscription launch without building a separate checkout, but speed is not the standard. Clean execution is.
Before launch, validate market coverage and compliance gates for your retainer flow by talking with Gruv.
In practice, the main difference is how collection happens. charge_automatically tries to charge the customer's default payment method, while send_invoice sends an invoice for manual payment. Some payment methods support only send_invoice, so the setup itself can limit what is possible.
Use auto-billing when the retainer amount and billing date are predictable, continuity billing is authorized, and a valid stored payment method is on file. Keep invoice approval when the buyer expects monthly AP or line-item review before payment. If procurement or scope review happens every cycle, invoice-led design is usually the safer fit.
Start with cards when speed and convenience matter most. Start with ACH for U.S. B2B retainers when lower-cost bank collection matters more than immediate confirmation. ACH has slower settlement and requires stronger authorization and return handling.
Use SEPA Direct Debit when collecting recurring payments from European payers in euros. Collection requires prior payer approval, including a signed mandate. SEPA Direct Debit is euro-only, so it is not a fit for non-euro billing.
Use automated retries for transient failures, but do not rely on retries alone. Route high-value retainers to human follow-up before service restriction so you do not treat every account the same way. Also separate retryable failures from cases that need updated payment details or a new mandate.
Define billing cadence, charge basis, change approval, failed-payment handling, and escalation ownership before rollout. Make sure your authorization record is easy to retrieve if a charge is questioned. If you cannot produce the customer's consent record or required bank mandate, you are not ready to scale automatic charging.
Treat PO requirements as a primary billing constraint. In PO-driven workflows, invoices may need a purchase order number, and some procurement policies pay only invoices that match an approved PO. Design around invoice workflows, PO capture, and PO validity tracking instead of assuming auto-charge will pass enterprise AP controls.
Yuki writes about banking setups, FX strategy, and payment rails for global freelancers—reducing fees while keeping compliance and cashflow predictable.
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.