Card-on-file (CoF) payments let a business store a customer's card details, with consent, so future charges can be processed without the customer re-entering their information. The stored data is almost never a raw card number. Instead, a payment processor such as Stripe or Adyen converts the card into a token held in a secure vault, keeping the primary account number (PAN) out of the merchant's systems entirely.
The three highest-value applications for Australian service businesses are:
- Subscriptions and recurring billing — monthly or annual charges run automatically against a stored payment method.
- Scheduled merchant-initiated services — trades businesses that book a return visit and bill on completion without requiring the customer to be present.
- One-click and off-session commerce — repeat purchases or delayed charges (such as no-show fees) where the customer has already authorised future billing.
For businesses ready to implement, the practical path is to choose a hosted checkout or embedded SDK from a PCI-DSS-compliant processor, capture explicit consent at the point of card save, and test both consumer-initiated and merchant-initiated flows before going live.
Key takeaways
Card-on-file payments require explicit customer consent, a tokenised storage approach, and active lifecycle management to reduce failed charges and disputes in the Australian market.
| Point | Details |
|---|---|
| Define your use case first | Decide whether you need recurring MIT billing, one-click CIT, or variable UCoF before choosing an integration pattern. |
| Use hosted or embedded flows | Hosted checkout or embedded SDKs keep PANs off your servers and reduce PCI scope to SAQ A in most cases. |
| Automate lifecycle management | Listen for token lifecycle events via webhooks and run a dunning sequence to recover failed recurring charges automatically. |
| Meet ACL consent requirements | Capture explicit, timestamped consent at card save and make cancellation as accessible as sign-up to comply with Australian Consumer Law. |
| MyAirCare shortens implementation | MyAirCare's built-in Stripe integration handles token storage, reminders, and receipts for Australian air-con businesses in one platform. |
Table of Contents
- What do card-on-file payments actually mean?
- Which business types benefit most from stored payment methods?
- How do CIT and MIT flows work in practice?
- What are the PCI-DSS and security obligations for Australian merchants?
- How do you keep stored cards working over time?
- How do you implement CoF payments as an Australian small business?
- How MyAirCare uses CoF in a real Australian booking flow
- What are the key risks and how do you reduce them?
- Managing consent under Australian regulations
- Handling disputes and chargebacks in Australia
- Integrating with Australian banks and payment gateways
- What does Australian Consumer Law require for recurring billing?
- Monitoring and auditing CoF transactions for fraud
- A practical perspective on CoF responsibility in Australia
- MyAirCare gives Australian air-con businesses a faster path to CoF payments
- Sources
What do card-on-file payments actually mean?
Card-on-file and tokenisation are related but distinct concepts. CoF describes the arrangement: a customer authorises a merchant to retain their payment method for future use. Tokenisation describes the mechanism that makes it safe: the processor replaces the card's PAN with a non-sensitive token string that has no value outside the vault that issued it.
The typical flow runs like this. A customer enters card details into a hosted checkout or embedded payment field. The processor receives the raw card data, validates it, and returns a token to the merchant's system. From that point, the merchant stores only the token. All subsequent charges reference that token, and the processor handles the actual card network communication.
A few terms appear repeatedly in provider documentation:
Vault — the processor's secure server environment where PANs and their corresponding tokens are stored and managed.
Token — a surrogate value (usually a string of characters) that maps to a real card inside the vault. Stolen tokens are useless without the vault and its encryption keys.
PAN — the 16-digit primary account number printed on a card. Merchants should never store this directly.
SetupIntent — Stripe's API object for saving a card without charging it immediately, used when the merchant intends to bill later.
PaymentIntent — Stripe's object for completing a charge; it can also save the card for future use when the setup_future_usage parameter is set.
Both Stripe and Adyen expose token vaults through their APIs, with Adyen using the concept of storedPaymentMethods and a recurringProcessingModel to manage how tokens are used in subsequent transactions.
Which business types benefit most from stored payment methods?
CoF adds measurable value wherever a business charges customers more than once or needs to bill after a service is delivered. Common use cases include:
- Monthly or annual subscriptions (software, memberships, maintenance plans)
- Scheduled trades services — fortnightly or quarterly air-con cleans, pest control, lawn care
- One-click repeat purchases in e-commerce
- Delayed or variable charges — no-show fees, post-job extras, incidental charges in hospitality
- Mobility and travel incidentals where the final amount is confirmed after the service
For a B2C subscription, the customer signs up, saves their card, and monthly charges run automatically. For a B2B scheduled service, the business books a quarterly visit, the customer saves their card at booking, and the merchant initiates the charge on completion without the customer needing to be present or re-enter details.
Pro Tip: For a small trades business starting out with CoF, begin with scheduled recurring services rather than variable post-job charges. The consent flow is simpler, the amounts are predictable, and the risk of disputes is lower. Variable charges (known as unscheduled CoF) require a separate consent step and are better introduced once the core recurring flow is working reliably.
How do CIT and MIT flows work in practice?
Two initiation models govern how a stored card is charged. Consumer-initiated transactions (CIT) occur when the cardholder is present and actively chooses to pay using their saved card, such as a one-click checkout. Merchant-initiated transactions (MIT) occur when the merchant charges the stored card under a prior agreement, without the cardholder being present at the time of the transaction.
MITs are the backbone of automated recurring billing. They require a clear prior agreement, documented consent, and typically a reference transaction ID that links back to the original CIT where the card was saved.
Payment methods can also be saved in two ways. Saving with a transaction captures the card during a live checkout, attaching the save to a real payment. Saving without a transaction uses a setup flow (such as Stripe's SetupIntent or PayPal's vault API) to store the card without an immediate charge, which suits free trials or delayed billing scenarios.
| Scenario | SetupIntent-style flow | PaymentIntent-style flow |
|---|---|---|
| Customer present at save | Yes | Yes |
| Authentication required at save | Yes (3DS at setup) | Yes (3DS at payment) |
| Off-session charging after save | Yes — primary purpose | Yes, with setup_future_usage set |
| Typical use case | Free trial, future billing, recurring service setup | Checkout with optional card save |
Adyen's equivalent is the recurringProcessingModel field, which distinguishes between Subscription, CardOnFile, and UnscheduledCardOnFile transaction types. Choosing the correct model matters because card networks apply different rules and liability shifts to each.
What are the PCI-DSS and security obligations for Australian merchants?
Australian merchants handling stored payment information are subject to PCI-DSS, the Payment Card Industry Data Security Standard. The practical goal for most small businesses is to reduce PCI scope as far as possible by ensuring raw card data never touches their own servers.
Scope reduction checklist:
- Use a hosted checkout page or an embedded SDK (such as Stripe Elements or Adyen Web Drop-in) so card data is entered directly into the processor's environment.
- Never log, store, or transmit PANs through your own application or database.
- Store only tokens returned by the processor.
- Use the processor's token vault for all subsequent MIT charges.
- Confirm with your processor which SAQ (Self-Assessment Questionnaire) tier applies — hosted-only integrations typically qualify for SAQ A, the lowest-burden tier.
Stripe, Adyen, PayPal, and ANZ Worldline all offer hosted or embedded payment components that support SAQ A eligibility. Each provider publishes documentation on their PCI scope reduction approach, and merchants should review those docs alongside their acquiring bank's requirements.
Tokenisation is the core security mechanism: tokens are non-sensitive substitutes for PANs, and a stolen token has no value without the vault and its encryption keys. This shifts the hardest security obligations to the processor rather than the merchant.
Under Australian Consumer Law, merchants also carry obligations around transparency and consent that sit alongside PCI-DSS. These are covered in detail in the consent and ACL sections below.
How do you keep stored cards working over time?
Stored cards fail when they expire, are reissued after fraud, or are replaced with a new number. Network tokenisation and account-updater services from card networks such as Mastercard and Visa automatically refresh stored card details when a bank reissues a card, reducing failed recurring charges without requiring the customer to re-enter their details.
Token lifecycle events exposed by processor APIs include created, updated, and disabled. A well-built integration listens for these events via webhooks and reacts accordingly: updating the stored token reference when a card is refreshed, flagging a payment method as inactive when it is disabled, and triggering a customer notification when no valid replacement is found.
Webhook and notification checklist:
- Listen for
payment_method.updatedandpayment_method.detachedevents (Stripe) or equivalent Adyen webhook notifications. - On a failed charge, attempt a retry after a short interval before notifying the customer.
- Send a pre-charge notification at least a few days before a scheduled MIT so customers can update their card if needed.
- Automate a card-update request email when a token is flagged as expired or disabled.
Retry and dunning logic should follow a graduated sequence: an immediate retry on a soft decline, followed by retries spaced over several days, with a customer notification sent after the first failure. Stripe Billing and Adyen's retry configuration both support automated dunning sequences that reduce the manual overhead of chasing failed payments.
How do you implement CoF payments as an Australian small business?
- Choose a merchant account and gateway. Select a processor that supports AUD settlement, account updater, and off-session MIT flows. Stripe, Adyen, PayPal, and ANZ Worldline all operate in Australia with local acquiring support.
- Pick a hosted or embedded integration. Hosted checkout pages offer the lowest PCI burden. Embedded SDKs (Stripe Elements, Adyen Web Drop-in) offer more UI control while still keeping card data off your servers.
- Capture explicit consent. At the point of card save, display clear language stating that the card will be stored and used for future charges. Record the timestamp and the consent text version.
- Implement the token save flow. Use a SetupIntent-style flow for saving without an immediate charge, or set
setup_future_usageon a PaymentIntent for saving during checkout. - Test CIT and MIT flows. Verify that on-session charges complete with 3DS authentication, and that off-session MITs process correctly using the stored token.
- Set up webhooks and retry logic. Configure event listeners for token lifecycle events and failed payment notifications. Implement a dunning sequence for recurring charges.
- Go live and monitor. Review failed payment rates, chargeback ratios, and token update events in the first billing cycle. Adjust retry timing if decline rates are higher than expected.
Cost categories to plan for include processor setup (often no upfront fee for Stripe or PayPal), per-transaction fees (typically a percentage plus a fixed cent amount per transaction in Australia, varying by processor and card type), and development time for integration, which ranges from a few hours for a hosted checkout to several days for a fully embedded custom flow.
For businesses using MyAirCare, the platform's built-in Stripe integration handles steps 2 through 4 out of the box, shortening the path to a live CoF flow considerably. Practical guidance on structuring payment terms alongside CoF is covered in the invoice payment terms guide for air-con cleaners.
How MyAirCare uses CoF in a real Australian booking flow
An air-con cleaning business using MyAirCare illustrates the practical workflow. A customer visits the business's branded booking page, selects a recurring quarterly clean, and enters their card details during checkout. MyAirCare captures the card via Stripe's hosted fields, stores the token, and confirms the booking. Automated reminders go out before each scheduled visit. When the job is completed, the merchant initiates the charge against the stored token without the customer needing to re-engage.
Benefits for small service businesses operating this way:
- Fewer missed or late payments because billing is automated rather than invoice-dependent.
- Faster checkout for returning customers who do not re-enter card details.
- Lower admin overhead from automated reminders and receipts.
- Better customer retention from a frictionless repeat-booking experience.
Pro Tip: For variable post-job charges, such as additional refrigerant or parts, use an unscheduled CoF (UCoF) transaction. This requires a separate consent step at booking — for example, a checkbox stating "I authorise charges for additional materials at the technician's discretion, up to $[amount]." Document that consent with a timestamp. Adyen's card-on-file knowledge hub distinguishes UCoF from standard recurring CoF and explains the different processing rules that apply.
What are the key risks and how do you reduce them?
The most common CoF mistakes are consent failures, poor receipting, and inadequate dispute records. Each creates exposure under Australian Consumer Law and card network chargeback rules.
Silent saves occur when a merchant stores a card without the customer's clear knowledge. This is a consent failure and a potential ACL breach. The fix is explicit opt-in language at the point of card capture, separate from general terms and conditions.
Poor terms and conditions that bury recurring billing clauses in fine print increase chargeback risk. Card networks and the ACCC both expect clear, prominent disclosure of what will be charged, when, and how the customer can cancel.
No receipts or pre-charge notifications leave customers with no record of what was agreed. Send a confirmation email at card save and a reminder before each scheduled charge.
For dispute handling, the process is: gather the original consent record (timestamp, consent text, IP address), the transaction receipt, any service delivery confirmation (job completion notes, photos), and the pre-charge notification. Submit these to the acquiring bank within the chargeback response window. Keeping these records in a centralised system, rather than scattered across email threads, is the practical difference between winning and losing a dispute.
Managing consent under Australian regulations
The Australian Competition and Consumer Commission (ACCC) expects merchants offering recurring or stored-card billing to obtain clear, informed consent before storing a card or initiating a charge. The consent must be specific: it should identify what will be charged, the amount or how it will be calculated, the frequency, and how the customer can cancel.
Practical consent requirements for Australian merchants:
- Present consent language at the point of card save, not buried in a terms-of-service page.
- Use plain English: "Your card will be saved and charged $X on the [date/frequency] for [service]. You can cancel at any time by contacting us."
- Provide a written confirmation (email or SMS) immediately after the card is saved.
- Make cancellation straightforward — the ACCC's guidance on subscription services holds that cancellation must not be materially harder than sign-up.
- Retain consent records with timestamps for at least the duration of the billing relationship plus a reasonable dispute window.
Pre-charge notifications sent a few days before each MIT give customers the opportunity to update their card or cancel, reducing both failed payments and disputes. MyAirCare's customer terms page provides an example of how consent and recurring billing terms can be presented transparently.
Handling disputes and chargebacks in Australia
Australian cardholders can dispute a transaction through their issuing bank under card network rules. The chargeback process typically gives merchants 30–45 days to respond with evidence, depending on the card scheme and the reason code.
For CoF and recurring billing disputes, the most effective evidence package includes:
- The original consent record (date, IP address, consent text version).
- The transaction receipt and the pre-charge notification sent before the MIT.
- Service delivery confirmation — for trades businesses, job completion notes, before-and-after photos, or a signed job sheet.
- Any correspondence showing the customer was aware of and agreed to the charge.
Merchants should maintain an audit trail in their booking or CRM system rather than relying on email search. Stripe's dashboard, Adyen's Customer Area, and ANZ Worldline's merchant portal all provide transaction-level records that can be exported for dispute responses.
Friendly fraud — where a customer disputes a legitimate charge — is reduced by clear pre-charge notifications and easy cancellation. A customer who received a reminder and could have cancelled has a weaker dispute case than one who received no notice at all.
Integrating with Australian banks and payment gateways
Australian merchants have several gateway options that support CoF transactions with local AUD settlement. Stripe and Adyen both offer full local acquiring in Australia, meaning funds settle directly in AUD without currency conversion. ANZ Worldline (formerly ANZ eGate) provides local bank-backed acquiring for businesses that prefer a major bank relationship. PayPal supports saved payment methods and recurring billing in Australia, though its acquiring model differs from direct card network acquiring.
Key considerations when selecting a gateway for CoF in Australia:
- AUD settlement and local acquiring — confirm the processor settles directly in AUD and holds a local acquiring licence or partnership.
- Account updater support — not all gateways in Australia pass through Visa and Mastercard account updater services. Confirm this feature is available on the plan selected.
- 3DS2 support for CIT flows — Strong Customer Authentication via 3DS2 is increasingly expected for on-session card saves. Verify the gateway's hosted fields or SDK supports 3DS2 natively.
- MIT exemption handling — the gateway should correctly flag MIT transactions so card networks apply the appropriate rules and liability shifts.
- Developer documentation quality — Stripe and Adyen publish detailed Australian-specific integration guides. ANZ Worldline's documentation is more limited, which increases integration effort.
Businesses integrating directly with an Australian bank's gateway should also confirm that the gateway's tokenisation approach is compatible with their chosen platform. MyAirCare's Stripe integration handles this compatibility layer, removing the need for custom gateway work.

What does Australian Consumer Law require for recurring billing?
The Australian Consumer Law (ACL), administered by the ACCC and state consumer affairs agencies, applies to all recurring billing arrangements entered into with Australian consumers. The ACL's unfair contract terms provisions are particularly relevant: a term that allows a merchant to charge a consumer's card without clear prior notice or that makes cancellation unreasonably difficult may be deemed unfair and therefore void.
For CoF and recurring billing, ACL obligations include:
- Disclosure — the existence of recurring charges and the card-save arrangement must be disclosed clearly before the customer agrees.
- Cancellation rights — customers must be able to cancel a recurring arrangement without unreasonable barriers. Requiring a phone call during business hours when sign-up was online is a common compliance gap.
- Refund obligations — if a charge is made in error or after a cancellation request, the ACL's consumer guarantee provisions require a prompt refund.
- Unfair contract terms — automatic renewal clauses that are not prominently disclosed, or terms that allow the merchant to change the charge amount without notice, are at risk of being found unfair.
The ACCC has taken enforcement action against businesses with opaque subscription and recurring billing practices. Merchants should review their terms against the ACL's unfair contract terms framework and ensure their cancellation flow is as accessible as their sign-up flow.
Monitoring and auditing CoF transactions for fraud
Fraud monitoring for CoF transactions in Australia should focus on two risk areas: unauthorised use of stored tokens and unusual MIT patterns that may indicate account compromise.
Recommended monitoring practices:
- Set velocity rules in the payment gateway to flag multiple charges against the same token within a short period.
- Monitor for MIT transactions that deviate from the agreed schedule or amount, particularly for unscheduled CoF.
- Review declined-then-approved patterns, which can indicate card testing against stored tokens.
- Enable fraud scoring tools available in Stripe Radar, Adyen's RevenueProtect, or equivalent gateway fraud modules.
- Conduct a monthly reconciliation of active stored tokens against current customer records, disabling tokens for customers who have cancelled or are inactive.
- Retain transaction logs for a minimum of seven years to meet ATO record-keeping requirements and to support any future dispute or regulatory inquiry.
The Australian Cyber Security Centre (ACSC) and the Australian Payments Network (AusPayNet) both publish guidance on payment fraud prevention that is relevant to merchants operating CoF arrangements. AusPayNet's fraud reporting data provides context on card-not-present fraud trends in Australia, which is the risk category that CoF transactions fall into.
A practical perspective on CoF responsibility in Australia
The technical side of card-on-file payments is well-documented by processors. The part that is less often discussed is the gap between having a working CoF integration and running it responsibly over time.
Many small businesses implement CoF correctly at launch, with good consent language and a working webhook setup, and then let the operational side drift. Tokens accumulate for customers who cancelled months ago. Pre-charge notifications stop going out because someone changed the email template. Retry logic runs indefinitely on a card that will never succeed. These are not technical failures. They are process failures, and they are where disputes and ACL complaints originate.
The practical recommendation is to treat CoF as an ongoing operational process, not a one-time integration task. Audit stored tokens quarterly. Confirm that consent records are being captured and retained. Test the cancellation flow from the customer's perspective at least once a year. Start with a hosted checkout and a SetupIntent-style flow to keep PCI scope minimal, then scale to MIT automation once the consent and lifecycle processes are solid.
MyAirCare gives Australian air-con businesses a faster path to CoF payments
Air-con cleaning businesses that want the benefits of stored payment information without building a payment integration from scratch have a direct route through MyAirCare. The platform combines online booking, automated reminders, Stripe-powered payments, and customer receipts in a single workflow — so the card save, the consent capture, and the post-job charge all happen within the same system rather than across separate tools.

The built-in Stripe integration means PCI scope is handled at the processor level, and businesses do not need to manage token vaults or webhook infrastructure independently. Automated reminders reduce failed payments by prompting customers to update their card before a scheduled charge. Receipts and booking confirmations are generated automatically, creating the audit trail needed for dispute responses.
Businesses can see the booking and payment flow in action on the MyAirCare booking page. To get started or review plan options, visit Myaircare.
Sources
- What Does Credit Card on File Mean? | Stripe
- Checkout
- Managing tokens | Adyen docs
- Secure card‑on‑file | Mastercard
This article is general information, not a substitute for advice from a qualified financial advisor. Consult a qualified financial professional about your own circumstances before acting on anything here.
