Privacy Policy
Gallantree Pty Ltd, trading as Token Gesture, handles personal information under the Privacy Act 1988 (Cth) and the Australian Privacy Principles. This policy describes what we collect when you apply for underwriting, what we do with it, and who else sees it.
We never hold card numbers. Card entry happens on the processor’s hosted payment page, not on our infrastructure. No cardholder data is stored, processed or transmitted by us, which is also why our PCI scope is SAQ-A.
1. What we collect, and when
When you apply
- Your legal entity name and trading site
- Your merchant category — 5967, 7273, 5122, 7995, or a description if none fits
- Expected monthly volume, and your chargeback ratio over the last twelve months
- A work email address, which becomes your merchant portal account
- Anything you tell us about a prior termination or a MATCH listing
As the application proceeds
- Processing history — sales, refunds and disputes, or projections if you are new
- Compliance documents: billing descriptor, refund policy, age-verification method, moderation policy, and test credentials where your site is gated
- Identity and beneficial-ownership information for directors, where an acquirer requires it
Automatically
Server logs — IP address, user agent, the paths requested — retained for retention period to confirm. The public site sets no cookies, uses no analytics and embeds nothing from a third party; the merchant portal and the admin console set a session cookie so you stay signed in. If that changes we will say so here on the day it changes.
2. Two things we do not do
- We do not pull consumer credit. Underwriting reads your business, not any director’s personal credit file.
- Nothing reaches a card scheme before you accept an offer. No scheme database is queried or written on the strength of an application alone.
3. Your prior processor
When you continue past the first step of the application, you agree that we may contact your previous processor for a reference. We ask them what they saw: volumes, dispute ratio, and why the relationship ended. We do this because a high-risk file cannot be underwritten on self-reported numbers alone, and because finding out later is what actually ends applications.
We will tell you who we intend to contact. If you would rather we did not, say so — it does not end the application, but it changes what we can conclude from the file.
4. MATCH
MATCH — Mastercard’s Member Alert to Control High-risk Merchants — lists merchants whose processing relationship was terminated for cause, and a listing persists for five years. Where we act as a sub-merchant sponsor under an acquirer, we may be required both to query MATCH before boarding and to report a termination to it.
We will not report you to MATCH without first telling you in writing what we intend to report and why, and giving you notice period to confirm to respond. An entry that already exists against you is a fact in the file. It changes which rate card you land on, not whether we read the rest.
5. Who else sees it
| Recipient | What they receive | Where |
|---|---|---|
| Acquiring bank | Underwriting file, identity documents, processing history | To confirm |
| Verotel International B.V. | Transaction and subscription data while Verotel is merchant of record | Netherlands |
| MongoDB Atlas | All application and subscription records | Region |
| Railway | Application hosting, server logs | Region |
| Your prior processor | A reference request naming your entity | Varies |
Several of these are outside Australia, so APP 8 applies: before disclosing your information overseas we take reasonable steps to ensure the recipient handles it consistently with the Australian Privacy Principles. We do not sell personal information, and we do not disclose it for marketing.
6. How long we keep it
- Declined applications — period to confirm, then deleted. We keep the decision and the reason, because you are entitled to it in writing.
- Boarded merchants — for the life of the relationship and seven years after it ends, which is the record-keeping period our obligations require.
- Webhook events — the gateway stores the full raw payload of every processor callback, permanently and by design, so a payment can be replayed and reconciled years later. Those payloads carry transaction and subscription identifiers, not card numbers. Whether a deletion job exists or only an intention — to confirm.
7. Security
Access to merchant data is restricted to staff who need it, and administrative actions are written to an audit log. API keys authenticate a service rather than a person and belong on a server; if one is exposed in a browser bundle, rotate it and tell us. Processor postbacks are signature-verified before they are processed and deduplicated by processor event ID.
8. Access, correction and complaints
You can ask for a copy of what we hold about you and ask us to correct it. Write to privacy officer and address to confirm. We respond within 30 days.
If you are not satisfied with how we handled it, you can complain to the Office of the Australian Information Commissioner at oaic.gov.au.
9. Data breaches
If a breach is likely to cause you serious harm we will notify you and the OAIC as soon as practicable, as the Notifiable Data Breaches scheme requires, and tell you what happened, what was exposed and what to do about it.