Merchant Services Agreement

Parties: OneTap Payments Pty Ltd (OneTap), New South Wales, Australia, and the Merchant identified in the Order Form.
OneTap ACN/ABN and business address: CONFIRM
OneTap contact: hello@onetap.au | 0423 512 185
Effective date: the date both parties accept the Order Form, after the open items in it are completed.

This agreement includes these terms, the Order Form and Schedule 1. The Order Form prevails on an expressly identified commercial or integration point. Check the final integration and checkout before signing. CONFIRM: versioned acceptance and actual launch backend.

1. Service and roles

OneTap provides embedded checkout and an agreed API integration for the Merchant's Group Orders. The Merchant is the seller. It sets product, price, tax, availability, reservation and cancellation terms; fulfils orders; handles product complaints and refunds; and receives purchase funds through its payment service provider (PSP). OneTap is responsible for its own checkout, calculations and payment coordination, and does not take custody of the purchase price. PSP terms govern processing and payout. Stripe is the first supported PSP; another requires a separately agreed, tested integration. Neither party claims a particular financial-services licensing treatment. CONFIRM: Australian payments-law review.

An Organiser starts a group checkout and proposes Participants and allocation. A Participant is a person invited to pay a Share; the Organiser is also a Participant if allocated a Share. A Group Order is one Merchant order, even if Shares are described by ticket or item. A Group Deadline is the disclosed deadline for authorising all required Shares. Authorisation is a PSP approval or hold for a payer's disclosed amount; capture turns it into a charge. A Completed Purchase requires successful capture of every required Share and the Merchant's confirmation of the order or booking. PSP payout may follow later. Separate ticket allocation does not create a separately fulfilled entitlement unless the Order Form and checkout expressly say so. CONFIRM: any individual-ticket model.

2. Order creation and accurate checkout

The Merchant will send accurate order data through the agreed API: its identity, order reference, items or booking, currency, price and tax, stock, allocation rules, Group Deadline, policies and fees. It will update an order promptly if price or availability changes. OneTap will validate order and Share totals, present each payer's amount and reject inconsistent requests. Changing an accepted amount requires fresh authorisation or checkout. No payer silently backs another's shortfall.

The Merchant must disclose its reservation policy and either hold sufficient capacity for the promised period or explain that availability is unreserved. It must not describe a pending Group Order or one captured Share as a confirmed purchase. The Merchant will identify itself as seller in checkout, receipts and PSP descriptors where permitted. CONFIRM: actual descriptor and receipt flow. OneTap will pass agreed status updates; the Merchant must check authoritative status before fulfilment because a notification alone does not prove completion.

The Merchant permits OneTap to display its name, marks, items and policies for checkout and purchase messages. Each retains its intellectual property; unrelated promotion needs consent.

3. Payment authority and funds

The Merchant authorises OneTap to use only the provider-supported PSP connection or API authority agreed in the Order Form for the Merchant's existing PSP account to create payment requests and individual authorisations, request capture of each payer's accepted amount for the specific Group Order, cancel uncaptured authorisations on expiry or permitted cancellation, query status and reconcile results. No operation may exceed the amount the payer accepted or change the recipient Merchant. OneTap will not initiate a subscription, recurring charge or unrelated later charge under this authority. OneTap may initiate a PSP refund only where the Order Form expressly grants that authority and the PSP connection permits it, within the agreed conditions and limits. Otherwise, OneTap will promptly coordinate with the Merchant and PSP to obtain a required refund without purporting to exercise refund authority it does not hold. This does not limit OneTap's responsibility to correct its own errors or refund its own fees where legally owed. CONFIRM: exact PSP permissions, account structure, refund authority and funding.

The Merchant maintains its existing PSP account, eligibility and fees, and grants only necessary integration authority. The Order Form must identify the Merchant PSP account, provider-supported connection or authorised credential method, actual permissions and scopes, and approved delivery, storage, rotation and revocation. It does not require the Merchant to create a new PSP account or use a particular account-connection product. Neither party will expose reusable secrets in browsers, URLs, analytics or routine support messages. OneTap will restrict credential access and isolate Merchants' data and authority; the Merchant will protect its account and revoke compromised access.

OneTap will reconcile individual PSP outcomes with Group Order status and check duplicate, late or out-of-order requests and events. CONFIRM: implemented controls and status source. The Merchant will help investigate disputed transactions. Neither party guarantees fraud prevention or chargeback success.

4. Deadline, extensions and failure handling

Until all required Shares are authorised, the Group Order is pending. At the Group Deadline, an incomplete group cancels by default: OneTap requests cancellation of uncaptured authorisations and the Merchant releases the related inventory reservation under its disclosed policy. Bank or issuer timing controls when a released hold stops appearing to a payer. A released hold is not a refund of a captured charge.

An extension requires valid authorisations and inventory reservations, and advance payer permission or fresh agreement. It cannot extend an individual PSP authorisation. Expired holds or reservations require reauthorisation or a new checkout. CONFIRM: maximum extension, notice, consent and reservation checks.

After all required authorisations, OneTap may request individual captures within its authority. Some can fail after others succeed. The Group Order remains pending if any capture, booking or Merchant confirmation is unresolved. OneTap will identify affected Shares, stop improper further captures, notify the Merchant and coordinate recovery. The Merchant will promptly decide whether fulfilment is possible and approve lawful cancellation, reauthorisation or refund under the Order Form's partial-failure process; OneTap may execute only actions within its agreed PSP authority. The Order Form must set the approval route, responsible actor, funding, timing, shopper notice and escalation for a partial failure, including when a refund fails. The Merchant funds sale-related refunds; OneTap funds correction of its own service errors to the extent it caused them, including its own fees where legally owed. Neither party may delay a remedy owed by law. CONFIRM: recovery owner and deadline, shopper notice, inventory and fee treatment, refund authority.

A captured charge requires a PSP refund; releasing a hold cannot reverse it. Both parties will track refund requests and outcomes. The Merchant funds lawful and policy refunds for its sale; OneTap coordinates correction of its errors and may submit a PSP refund only within the authority described in section 3. The parties will follow the Order Form's funding, timing and escalation process for a failed refund or insufficient funds and inform the payer. CONFIRM: escalation and refund-status process.

5. Shopper support and disputes

The Merchant handles product, booking, delivery and change-of-mind issues; OneTap handles checkout, Share and payment-status problems. Each will route mixed complaints promptly, identify the next owner to the shopper and share relevant evidence subject to privacy and PSP rules. Both will cooperate on chargebacks and regulator enquiries without discouraging statutory rights. CONFIRM: support contacts, response targets and escalation owner.

6. Privacy, security and marketing

Schedule 1 governs personal information. Each party will comply with applicable privacy, security and marketing law and safeguard the data and authority it handles. At launch, only the Merchant may send its own promotions, with a lawful basis, sender identification and unsubscribe. OneTap may transmit a Merchant-specific marketing choice only when its wording, sender and evidence are agreed and implemented. No Organiser invitation or ambiguous choice counts as the invitee's marketing consent. OneTap has no launch permission for consumer promotions or a consumer card. CONFIRM: consent implementation.

On a suspected incident affecting shared data, the discovering party will notify the other promptly and cooperate on containment, evidence and required notices. CONFIRM: incident contacts and timing. Neither claims an unverified hosting location, certification or card-data arrangement.

7. Fees and records

The Order Form must state OneTap fees, calculation, taxes, collection, due dates and failed or refunded-order treatment. Only agreed fees may be charged, with payer disclosure where relevant. The Merchant sets product price and tax and pays its PSP fees. Both will correct demonstrated invoice errors. CONFIRM: fee model and shopper-fee treatment under card rules and PSP terms.

Each will keep necessary records and share transaction evidence for complaints, refunds or chargebacks, subject to privacy and security controls.

8. Term, changes and ending the service

Either party may end this agreement on CONFIRM: period written notice, or for material breach uncured within CONFIRM: cure period after notice. Earlier termination is available where law, PSP rules or serious security or fraud risk requires it. OneTap may proportionately suspend affected functionality for credible security risk, unlawful use, PSP restriction or material non-payment, with advance notice where practicable and an explanation when lawful and safe.

On termination, the parties will stop new orders, resolve pending groups under section 4, inform shoppers, revoke OneTap's PSP/API access and handle data under Schedule 1. Accrued obligations continue.

OneTap may propose prospective changes with reasonable notice. Material price, payment-authority, data-use or risk changes require the Merchant's agreement. If they do not agree, either may exit without a new termination fee; existing orders keep their accepted terms. Legally or PSP-required changes may take effect sooner with practicable notice.

9. Responsibility and disputes between the parties

Each party bears loss caused by its own breach, negligence, fraud or misconduct to the extent recognised by law, and will reasonably limit loss. The Merchant answers for its stock, policies and supply; OneTap answers for its calculations, integration and security. OneTap will use reasonable care and skill but cannot promise uninterrupted service, perfect fraud detection or chargeback outcomes. Nothing limits non-excludable liability or applicable consumer and small-business protections.

Liability limit for commercial review: No general cap is agreed in this draft. CONFIRM: fair monetary cap, basis and any higher data/security cap; legally review carve-outs for shopper amounts, refunds, fraud, wilful misconduct, confidentiality, personal information and non-excludable liability. No blanket transfer of all chargeback losses.

The parties will escalate disputes to business contacts for CONFIRM: period before litigation, preserving urgent relief and statutory complaints. New South Wales law and non-exclusive jurisdiction apply, subject to mandatory law. Notices go to Order Form contacts; email requires reasonable evidence of receipt. Assignment that materially increases the other's risk requires consent, except to a successor assuming the obligations with notice.

Order Form — complete before signature

Item	Agreed entry
Merchant legal name, ABN/ACN, address and notice contact	CONFIRM
Start date, term and convenience notice period	CONFIRM
Merchant site, product or booking categories and territories	CONFIRM
Integration specification, API version, status interface and notification method	CONFIRM
PSP, existing Merchant account, provider-supported authorised connection or credential method, permissions, scopes and revocation	Stripe first; CONFIRM account, method and scopes
Group Order model, allocation, separate-ticket rights if any	One group order by default; CONFIRM exceptions
Group Deadline, reservation rules, maximum extension and payer notice/consent	CONFIRM
Cancellation roles, partial-capture approval and correction process, refund authority and limits, funding, timing, failed-refund escalation and shopper notice	CONFIRM
OneTap Merchant fee: basis, tax, invoice/deduction, due date, failed/refunded-order treatment	CONFIRM
Shopper fee: amount/formula, charging party, tax, disclosure and refund treatment	CONFIRM
Support, fraud review and incident contacts; service targets if any	CONFIRM
Liability cap and legally reviewed exceptions	CONFIRM
Required shopper and fulfilment fields and any marketing choice	CONFIRM

Schedule 1 — data and operational responsibilities

1. Purpose and source. The Merchant supplies order, price, policy, reservation and, where applicable, Organiser information. Each payer supplies their own payment and required contact details; the PSP supplies payment references and outcomes. OneTap uses these to run checkout, send purchase invitations or status messages, reconcile payments, support shoppers and address security or legal needs. Each party will collect only information needed for these purposes, provide its own required privacy notices and maintain the lawful basis for its own use.
2. Merchant access. OneTap will disclose to the Merchant its own order and payment states and the names and contact or fulfilment details actually needed to identify customers and complete that order. Full billing addresses are included only where a defined payment, tax, fraud or fulfilment need requires them; the Merchant's PSP account may independently expose billing details under its PSP terms. CONFIRM: field-by-field necessity, PSP visibility and authenticated delivery. OneTap will use Merchant-scoped access controls and an authenticated status interface; any event notification must be authenticated and checked for duplicates. CONFIRM: implementation, retry and reconciliation design.
3. Protection and access. Each party will limit staff and contractor access, protect credentials, keep reasonable logs and restrict data to the relevant Merchant and order. The Merchant will protect information received from OneTap and avoid adding it to a general marketing list without a lawful basis. OneTap will not send raw card details through its application if checkout uses the PSP's hosted payment collection; CONFIRM: actual payment-element and token flow. Neither party warrants a particular hosting region or security certification until verified.
4. Marketing. Purchase invitations, reminders, receipts, fulfilment and support messages are operational only to the extent their actual content serves those purposes. Promotional content in any of those messages requires any consent required by applicable marketing law, sender identification, unsubscribe and suppression controls. At launch, only the Merchant may send its own promotions; OneTap has no permission to promote to shoppers or offer a consumer card. The Merchant bears responsibility for its promotional content and controls. A contact supplied by an Organiser is not by itself marketing consent from that contact. A OneTap-transmitted opt-in, if enabled, must identify the Merchant as sender and carry evidence of that individual's choice; it is not transferable consent to OneTap or another Merchant.
5. Retention and exit. Each party keeps personal information only as long as needed for the purchase, support, disputes and legal obligations, then deletes or de-identifies it where required. The specific retention periods, backups, deletion method and any legal hold are CONFIRM in the integration/data schedule before launch. On exit, the parties will securely return or delete shared information on a documented timetable, except records each must retain lawfully, and will restrict retained records to those purposes. Neither party will use the other's customer records for a new purpose after exit.