The same transaction, in the same app

The moment after the payment

What you receive

What one record becomes

Those three arrivals are the raw material. Everything below is the same record, put to work for a different team in your building.

Start a conversation

Tell us which institution you are with, and which of these you would put in front of a customer first. A person replies, usually within one business day.

Prefer email? [email protected]

What the record carries

The category and the identity come off the same record

A merchant category code describes the business, not the basket, and the descriptor that reaches your feed is not the shop the customer walked into. Because the record carries the line items and the merchant's own verified identity, both problems resolve at once, from one source.

• Categories are assigned at the line, not at the transaction. One payment carries as many categories as the basket did, each with its own share of the total, and the lines still sum to the statement amount.
• The identity is supplied, not looked up. Trading name, ABN and location come from the merchant at the point they take the payment, not from a directory vendor's refresh cycle, so a rebrand or a move can never fall behind the payments it describes.
• One licence, not a stack of vendors. Merchant name, logo and category are usually three vendors reconstructing what the merchant already holds. Here the category is read off the items themselves, so there is nothing left for a second vendor to supply.
• Your taxonomy, not ours. Categories map to whatever scheme your app already uses, so nothing downstream is rebuilt to accept them.

It keeps updating after the sale

Proof of purchase, years later

A warranty claim today is a contest of memory: the customer against the retailer, over a strip of thermal paper that faded in a kitchen drawer. Because the record is written at the payment and never leaves it, the claim becomes a lookup. The customer opens the transaction in your app; the merchant resolves the same record and sees the same items.

• Cannot be doctored. Written before the customer ever touches it, so the retailer can trust it exactly as much as the customer does. One source of truth, nothing to argue about.
• Sessions with real intent. People hunt for receipts constantly: a warranty, a return, an expense claim. Today that search ends in a shoebox or a retailer's app. Held against the transaction, it starts and ends in yours, and every year of records deepens the reason to stay.
• The record travels further. The same verified proof serves an insurance claim or an expense report, released only with the customer's consent, granted from your app.

Tax time, from the same record

The ATO expects substantiation for a deduction, and what most cardholders hold is a lost paper receipt or a statement line that proves an amount but not an item. The record already carries GST-tagged line items, the merchant's ABN and the purchase date, so an end-of-year export is a product of what exists, not a reconstruction. The cardholder filters a year to their deductible categories and hands their tax agent evidence written at the point of sale, from your app.

The primitive under everything else here

Every other page on this site is this record, put to work. Nothing below is a separate product or a separate feed; it is one record, read four ways.

One basket becomes one category, so the breakdown shows a number the customer knows is wrong. They correct it by hand a few times, then stop opening the feature. The data is the ceiling, and no amount of design lifts it. Line items raise the ceiling, and everything built on top gets better at once.

Item-level budgeting, inside the bank app

What the basket makes possible

Patterns the customer cannot see for themselves

A year of line items is a record of habits nobody keeps deliberately. Read across it and the app can tell the customer something true about their own spending that they would never work out by scrolling a list of totals.

• Price creep on the things they buy every week. The same item, same shop, quietly up 14% since March. A merchant total cannot separate that from buying more of it.
• The same item, cheaper elsewhere. They already shop at both places. One of them is charging them more for the identical product.
• A habit forming. Twice a week became five times a week over a few months. That is a line the customer would recognise instantly and never spot alone.
• Where the money actually leaks. Not "Groceries, $940". The $180 of it that was snacks bought at service stations at 6pm.
• Subscription drift. A renewal that went up, a plan they stopped using, a duplicate of something they already pay for under a different merchant name.

Every one of these is an insight the customer values and a reason to open the app, and none of them can be produced from a descriptor and an amount.

Why it keeps getting used

• Nothing to correct. Every manual re-categorisation is the feature admitting it got it wrong, and each one costs a little more trust than the last.
• It works on day one. The history is already itemised, so a customer opening the feature for the first time sees a year of accurate spend rather than an empty state that fills in slowly.
• It is yours, not a bolt-on. The breakdown lives with the money, in the app the customer already opens, rather than in a separate budgeting product they have to be sold on.

What makes all of it work is the record underneath: smart receipts, categorised at the line.

The feed is the one connection a business bank already owns into its customer's accounting system. It is trusted, it is automatic, and it is carrying about a fifth of the information the customer actually needs. Everything the bookkeeper does next exists because the line items, the GST per line and the tax invoice did not travel with the payment.

What the same transaction costs to process

Industry benchmarking puts the international average at US$9.40 per invoice against US$2.78 for best-in-class performers, over an average of 9.2 days and a 22% exception rate. The gap between those numbers is almost entirely re-keying and chasing documents, which is what a shared record removes.

What changes for the customer

• The bank line arrives itemised. Line items and GST per line land against the transaction in the ledger, so the coding is already done rather than reconstructed from a shoebox at the end of the quarter.
• The tax invoice is attached, not chased. The ATO requires a valid tax invoice to claim a GST credit above A$82.50. The rail does not carry one. The record does.
• Reconciliation stops being a task. The same figure is currently re-keyed across point of sale, bank, processor, ledger and ERP because none of them share a record. One record ends that.
• It works through the connection you already have. No new integration for the customer, no new app for their bookkeeper, no change to the accounting platform they chose.

What changes for you

BAS that is ready before the quarter ends

The quarterly statement is the ledger problem at scale: an accountant with fifty small-business clients rebuilds fifty quarters of GST coding every three months. Because the GST is tagged per line at the point of sale, by the infrastructure rather than corrected by a human afterwards, the BAS is largely assembled by the time the quarter closes. The accountant reviews and lodges, fifty times, instead of reconstructing fifty times.

The corporate card without the expense report

Expense claims run on self-reported descriptions and photographed receipts, and finance teams spend their time cross-referencing the two. With the record written at the swipe, the claim is the receipt.

• Nothing is uploaded, nothing is embellished. Finance sees the verified line items, merchant, category and GST split for every corporate card purchase, exactly as the point of sale produced them.
• Policy runs automatically. Merchant category allowed, spend within limit, approval triggered when a rule needs a human. Claims that match policy clear themselves.
• Your commercial card wins the deal. A corporate card program where the expense report disappears is a product argument no rate can match.

Sources: invoice volumes and manual processing share, Australian Treasury eInvoicing materials. Automation and manual keying rates, Institute of Finance and Management. Executive time on payment administration, small-business survey research. Australian document processing costs, ATO eInvoicing value assessment citing Deloitte Access Economics. International invoice cost, processing time and exception rate, industry-analyst benchmarking. GST tax invoice threshold, Australian Taxation Office.

First-party misuse, the dispute raised against a purchase the customer genuinely made, is expensive precisely because it is indistinguishable from the real thing at the point it arrives. You carry the investigation, the provisional credit and the merchant relationship for a transaction that was always legitimate. The cause is almost never dishonesty. It is a descriptor nobody can decode, weeks after the event.

The first two numbers describe the same mechanism: the cardholder comes to you, so an unrecognised charge becomes a dispute rather than an enquiry. The third is what happens when you can answer them. Visa reports certain subscription merchants deflecting as high as 90%, and more than US$60 million in confirmed first-party disputes deflected in total.

What it costs you now

On international transactions the dispute line is larger than the fraud line itself. Handling the dispute costs you more than the fraud that triggered it. From 1 October 2026 the Reserve Bank's Conclusions Paper reinstates the net cost of disputes and chargebacks as a recognised, eligible issuer cost, so for the first time the line is not only measurable but regulated.

Why it is worth attacking

What the cardholder sees instead of a dispute form

The dispute reaches the merchant in seconds, not cycles

When a cardholder does want out of a charge, the strange part is who finds out last: the merchant, the one party who can actually fix it. A subscription that should be cancelled, an order that never arrived, a double charge; the merchant could resolve any of them in a minute. Instead the claim crawls from you to the scheme to the acquirer and finally to the merchant, weeks later, with a case number attached.

• The customer saves money and gets it back sooner. A refund at the merchant is the full amount, in days, instead of a provisional credit that can be clawed back after a lost case.
• You skip the case entirely. No investigation, no provisional credit funding, no scheme fees, for every dispute the merchant resolves at the source.
• The relationship survives. A cancelled subscription handled in-app is a customer kept, for the merchant and for you. A chargeback is a customer lost to both.

The record already connects both ends, so the loop needs no integration beyond the one that delivers the receipt.

Real fraud surfaces faster too

The same detail runs in the other direction. A cardholder scanning a statement line can only ask themselves whether they were in that shop. A cardholder looking at the line items can tell you immediately whether the basket was theirs, because nobody forgets what they did not buy. Genuine unauthorised use gets reported in hours rather than at the end of a statement cycle, which is the window where recovery is still possible and the card can be stopped before the next attempt.

The view no single bank has

You see fraud signals from your own cardholders and your own dispute history. Each processor sees its own merchants. A fraudulent actor working across several banks and several processors registers a low signal at every one of them, and a strong signal in aggregate that nobody is positioned to read. Because the record sits across processors and merchants, the aggregate view exists in one place for the first time: every connected merchant's signals and every dispute event, against the same instruments.

Sources: cardholder behaviour, Datos Insights with Ethoca, and Chargebacks911; global vendor surveys, directional rather than Australian. Dispute deflection, Visa, Order Insight product disclosures. Issuer cost lines, RBA Issuer Cost Study (August 2025), Tables 1 and 3, collected from eleven institutions covering more than 90% of the Australian card-issuing market on a net-loss basis; the dispute line bundles disputes, chargebacks, collections and write-offs and is not a per-dispute cost. Eligible-cost change, RBA Conclusions Paper, effective 1 October 2026. Australian card fraud, AusPayNet FY2024-25 data tables.

Every purchase on your card, at an online retailer or a till in store, arrives with its line items attached. We track each cardholder across social media, online retailers and other data points. For purchases at physical locations, we use the geolocation of the merchant's terminal, recorded when the merchant onboards. Together that shows the full scope of their spending. Over months that becomes a profile of each cardholder: what they buy, where, how often, through which channel, and how that is shifting. That baseline is what makes unusual behaviour stand out, and the same baseline shows what the customer actually needs. One profile, built for anti-money laundering (AML) and fraud, that also makes your marketing accurate.

What the profile adds to the transaction feed

What goes into the profile

• How they shop on the website. Behaviour across the whole online session, from first visit to final payment: how they move through the site and the checkout, and whether the session behaves like a real person, a bot or someone being coached by a scammer. It shows how each customer shops, not just what they paid.
• Email and phone number. Whether an email is disposable or has appeared in a data breach, which of more than 350 social and online platforms an email or phone number is registered to, and how much digital history sits behind each.
• Device and network. A returning device is recognised even after a reset or in incognito mode, and checked for tampering, emulators and remote access. The IP address is checked for VPNs, proxies and data centres.
• Connections to other people. Emails, phone numbers, devices and networks shared across accounts link one cardholder to others, so fraud rings and mule networks show up as a group rather than as unrelated customers.
• Fraud history. Whether the email, phone number, device or IP address has been involved in fraud before, checked against a shared global fraud network.
• AML screening. Customer screening, payment screening and ongoing transaction monitoring, run against the same profile.
• Identity checks. ID document verification, liveness detection and proof of address, enriched with every signal above.

For AML and fraud

• Out of character is measurable. A cardholder who buys groceries and fuel and suddenly starts buying gift cards, electronics that resell easily or high-value goods at new merchants stands out against their own history, not a population average.
• Cash-like goods are visible. Repeated purchases of gift cards, prepaid cards and vouchers, split across merchants and channels, show up at the item level. A total-only feed sees ordinary spend.
• The alert arrives with its evidence. When a case is raised, the line items are already attached, so the review starts from what was bought rather than from a merchant string.
• Fewer good customers declined. A large purchase that fits how the customer usually shops is recognisable as normal, so it is less likely to be blocked.

For marketing

• Offers from real purchasing. A customer who starts buying nursery items, building materials or travel is signalling a need (insurance, a home loan top-up, a travel card) that a merchant category never reveals.
• Timed to the need. The profile updates with every purchase, so an offer can land when the need appears rather than months later.
• Less wasted spend. Offers reach the customers they fit instead of everyone in a segment built from totals.

Marketing use runs only with the cardholder's consent: opt-in, purpose-limited and revocable, in line with the Privacy Act's direct marketing principle (APP 7). AML and fraud monitoring continues whether or not a customer opts in.

Enrichment is what moves a message from the second number to the first. It is a message about a purchase the customer made minutes ago, which is why it gets opened, and it lands them inside your app rather than on somebody else's page.

The loyalty card is the card they already paid with

Every loyalty program fails at the same moment: the till. The stamp card is in a drawer, the app wants a password, the barcode will not scan and the queue is growing. SyncPay makes the payment itself the loyalty event: nothing to carry, scan or install. A missed scan stops being a missed retention event, because the earn happens on the payment whether or not anyone remembered the program exists.

1. The customer pays as normal. Any card, any terminal. Nothing changes at the counter for them or for the merchant.
2. The record is written at the sale. The same itemised record that carries the receipt is evaluated against the merchant's loyalty rules: spend thresholds, eligible items, campaign periods, multipliers.
3. A qualifying purchase earns automatically. Points, a visit or a credit land on the customer's balance at settlement, with no action from either side of the counter.
4. The reward surfaces in your app. Tier progress and anything waiting to be claimed appear against the transaction, next to the receipt it came from.

What it looks like against the transaction

Why it lands with the issuer

Sources: push opt-in and open rates, Airship Mobile App Push Notification Benchmarks 2026. Login volumes, Commonwealth Bank FY25 results. Card usage, RBA retail payments statistics and published Australian credit card data. Advertising costs, industry benchmarks.

"$9,400 a month at a wholesaler" is a growing shop restocking weekly, or a struggling one making desperate bulk orders, or one quietly buying a different grade of stock than it sells. The total is the same in all three. What was bought, how often, and from whom is where the risk actually lives, and no statement carries it. With the line items, you understand the risk fully before you lend, not after.

What the record adds to the statement

What that changes for business lending

• Serviceability from real purchasing. Input costs, stock turnover and spend discipline read directly from the line items rather than modelled from totals.
• Concentration risk is visible. A borrower dependent on one supplier looks exactly like a diversified one in a statement. It does not here.
• Drift is an early warning. Input costs creeping, order frequency falling, a supplier being swapped for a cheaper one: the patterns that precede an arrear show up in purchasing months before they show up in repayments.
• Priced, not declined. Uncertainty gets priced into margin or turned into a decline. Resolution lets you say yes, at the right price, to borrowers the statement alone would have cost you.

The same API serves consumer credit with the customer's explicit consent: purpose-limited, revocable and consumer-initiated, alongside the CDR bank feed rather than instead of it.

Most disputes already begin with a charge the cardholder cannot place. An agent-made charge is unrecognised by design: the human saw the instruction, never the checkout. When the charge looks wrong, the question stops being "do you recognise this purchase" and becomes "did the agent do what it was told", and today no system your cardholder touches can answer it.

Three records that never meet

Nobody links the three today. The record that already carries the receipt is built to. The same record that resolves a human purchase can hold the agent's identity, the instruction it acted on and what the merchant delivered, keyed to the payment your feed already shows.

Checked before the money moves, audited after

Linked records make verification possible at two points, and the two do different jobs. One stops a bad purchase from happening. The other proves what happened.

What verification looks like in your app

Fraud models built on humans stop working

Every fraud detector you run today was trained on human texture: the browser session, the device fingerprint, the typing rhythm, the time of day, the places a cardholder can plausibly be. An agent has none of it. It buys headless, from a data centre, at machine speed, at three in the morning, and so does every other agent, legitimate or not.

• Device and browser signals. There is no browser and no device. Ten thousand honest agents and one fraudulent one can share the same infrastructure and look identical.
• Behavioural biometrics. No mouse movement, no typing cadence, no hesitation on the payment page. The signals read "bot" on every transaction, because every transaction is one.
• Geolocation and impossible travel. The purchase comes from a server region, not a suburb. The "cardholder" is everywhere at once, legitimately.
• Velocity rules. A perfectly authorised agent might make forty purchases in a minute. Speed stops meaning anything.

Score an agent with those models and every legitimate purchase looks like fraud, while actual fraud looks exactly like everything else. The human texture the models depended on is gone, so the basis for the decision has to change.

Why this lands on the issuer

If that feed carries a descriptor and an amount, the agent inherits the human bookkeeper's job unchanged: guess the category, chase the document, put "SP* TFB PTY LTD 0417" in a query queue for the owner. Automation does not remove that friction, it runs it faster. A guess made at machine speed is a mis-coded ledger by the end of the day, not the end of the quarter.

The world is not ready for it yet

The agents exist. The data does not. There simply is not enough of it where the agent can reach it, so every "autonomous" accounting platform today runs on a supply chain of human effort:

• Manual uploads. Someone photographs the receipt and drags it in.
• Email feeds. Someone remembers to forward the invoice to an inbox the agent watches.
• OCR. A model squints at a crumpled scan and produces a guess that someone then has to check.
• Query queues. Whatever is still missing becomes a question for the owner at month end.

Every one of those paths ends at a person. Which means the agent is always waiting on a human: to upload, to forward, to confirm, to answer. That is not autonomy, it is automation with a human bottleneck moved to the end of the line.

Accurate needs clean, seamless needs embedded

The same transaction, read by an agent

A continuous close is only continuous if every transaction arrives complete. One incomplete feed and the "real-time ledger" is a query queue with better branding.

Where the issuer sits

And there is only more to come

1. We check the BIN locally.
2. We call the issuer's or processor's matching API.
3. The partner returns an ARN and a match confidence.
4. We verify amount, last 4 and time, then write the ARN to our receipt.
5. We push the itemised receipt and fraud signals back, keyed by the ARN.
6. The issuer stores it against their own transaction record.

One integration, not one per merchant

The work of reaching every retailer is done once, by us, and it does not land on your roadmap or theirs.

• The data sits inside the merchant's point of sale. The receipt lines and the fraud context never leave the till on their own.
• Sourcing it yourself is a build per retailer. Every merchant, every POS vendor and every format they use, negotiated and maintained separately.
• The merchant then repeats it per bank. Each institution their customers bank with asks them for the same work again.
• So it stalls before it starts. Both sides are waiting for the other to absorb a cost neither can justify alone.

Which leaves two ways to get the record.

Start the conversation

A matching API and a receipt push, still being worked through with prospective partners. Tell us which use case you would put in front of a customer first.

This is the shape we propose. It is a proposal rather than a fixed requirement: where your systems already emit something close, we adapt to it. The receipt lookup API is live today. The exchange is the design we are taking through our first issuer processor, so the field names are open for discussion and the open items at the bottom of this page are exactly that.

{
  "task": "Build the two endpoints SyncPay calls to exchange transaction data with our card issuing platform: a match endpoint that returns the rail-side identifier for a payment, and a receipts endpoint that accepts the itemised receipt and fraud signals for that payment.",
  "context": "SyncPay sits on the merchant side of the card rail and holds the itemised receipt for a payment. We sit on the issuer side and hold the authorisation and clearing record. Neither side can see the other's data through the card network. SyncPay filters on our BIN ranges, calls us with the match keys, we return ARN plus our reference, and SyncPay pushes the receipt keyed by ARN. Full card numbers are never exchanged.",
  "deliverables": [
    "POST {issuer_base_url}/syncpay/match accepting the match request below and returning the transaction identifier below, or {\"found\": false}.",
    "POST {issuer_base_url}/syncpay/receipts accepting an event envelope carrying the enrichment payload below. Idempotent on arn + event_type. Return {\"received\": true} within 5 seconds.",
    "Auth: mutual TLS or a signed JWT on a client credential we issue, IP allowlisted on both sides. Every payload carries X-Signature: hmac-sha256 of the raw body under a shared secret.",
    "A BIN range list in the format below, delivered once and again on change, so SyncPay can filter locally and never call us for a card that is not ours.",
    "Optional, if the ARN is only known at clearing: POST an arn.assigned event to {base_url}/issuer/events when it lands, so both sides backfill the ARN against the auth-time reference."
  ],
  "flow": [
    "1. POS accepts the payment and sends its normal payment event to SyncPay.",
    "2. SyncPay ingests: signature and duplicate checks, then the sale is written as a receipt with basket, amount, time, terminal, BIN, last 4 and processor fraud score.",
    "3. SyncPay checks the BIN against our range list locally. Not ours: stop, no call. Ours: SyncPay calls our match endpoint.",
    "4. We look up the authorisation and return ARN, auth timestamp, last 4, scheme, our reference, the issuer program and a match confidence.",
    "5. SyncPay confirms amount, last 4 and time, writes the ARN onto its receipt, and pushes line items plus fraud signals keyed by ARN.",
    "6. We store the enrichment against our transaction. Refunds and disputes follow as events on the same ARN."
  ],
  "value_formats": {
    "amounts": "Integer minor units. 1150 means 11.50. No floating point anywhere in the payload.",
    "timestamps": "ISO 8601 UTC, for example 2026-09-10T02:14:05Z.",
    "currency": "Explicit on every message, for example AUD. Never implied by the endpoint or the account.",
    "arn": "10 to 40 upper-case alphanumerics. 23 digits on Visa and Mastercard, variable on Amex."
  },
  "match_request": {
    "sptc": "SPTC7K2M9X4A",
    "card_bin": "451234",
    "card_last4": "4242",
    "scheme": "visa | mastercard | eftpos | amex",
    "amount_cents": 1150,
    "currency": "AUD",
    "auth_time": "2026-09-10T02:14:05Z",
    "auth_time_tolerance_seconds": 120,
    "merchant_id": "MID-0041823",
    "terminal_id": "T0142201",
    "auth_code": "081224",
    "rrn": "612345678901",
    "stan": "123456"
  },
  "transaction_identifier": {
    "found": true,
    "arn": "74567890123456789012345",
    "auth_timestamp": "2026-09-10T02:14:04Z",
    "card_last4": "4242",
    "scheme": "visa",
    "issuer_txn_ref": "ISS-AUTH-77120934",
    "issuer_id": "PRG-CU-014",
    "network_txn_id": null,
    "match_confidence": "exact | probable",
    "arn_status": "assigned | pending_clearing"
  },
  "event_envelope": {
    "event_id": "b7f3c2a0-1d4e-4f8a-9c6b-2e5d8a917f30",
    "event_type": "receipt.created",
    "created_at": "2026-09-10T02:14:07Z",
    "data": {}
  },
  "event_types": {
    "syncpay_to_issuer_core": [
      "receipt.created: the itemised receipt and fraud signals for a matched payment",
      "receipt.refunded: a full or partial refund against the same ARN",
      "receipt.disputed: a dispute or pre-dispute signal raised against the same ARN"
    ],
    "syncpay_to_issuer_optional": [
      "receipt.updated: line items changed after the sale, for example shipping or backorder fulfilment"
    ],
    "issuer_to_syncpay_optional": [
      "arn.assigned: the ARN for a previously matched auth-time reference, once clearing has run",
      "authorisation.created: mirror mode, you push every authorisation on a partner BIN and SyncPay matches locally instead of calling you"
    ]
  },
  "enrichment_payload": {
    "keys": { "arn": "74567890123456789012345", "sptc": "SPTC7K2M9X4A", "issuer_txn_ref": "ISS-AUTH-77120934" },
    "merchant": { "trading_name": "Example Cafe", "abn": "47312896204", "address": "12 Smith St, Fitzroy VIC 3065", "category": "cafe", "syncpay_merchant_id": "uuid" },
    "receipt": {
      "currency": "AUD",
      "lines": [
        { "description": "Latte", "quantity": 1, "unit_price_cents": 550, "line_total_cents": 550, "tax_cents": 50 },
        { "description": "Croissant", "quantity": 1, "unit_price_cents": 600, "line_total_cents": 600, "tax_cents": 55 }
      ],
      "subtotal_cents": 1045, "tax_cents": 105, "tip_cents": 0, "total_cents": 1150,
      "paid_at": "2026-09-10T02:14:05Z",
      "receipt_url": "https://syncpay.au/r/SPTC7K2M9X4A"
    },
    "card": { "last4": "4242", "scheme": "visa", "entry_mode": "chip | contactless | swipe | keyed | on_file" },
    "fraud_signals": {
      "processor_risk_level": "low | medium | high | null",
      "processor_risk_score": 12,
      "entry_mode_flags": ["contactless"],
      "offline_capture": false,
      "syncpay_rating": null
    }
  },
  "bin_range_list": {
    "format": "JSON array, or CSV with the same columns. Delivered once, then again on change, with a version so SyncPay can confirm it loaded the latest.",
    "row": { "issuer_id": "PRG-CU-014", "bin_start": "451234", "bin_end": "451239", "scheme": "visa", "effective_from": "2026-09-01", "effective_to": null }
  },
  "design_rules": [
    "BIN check is local. SyncPay never calls you for a card outside your ranges, which is most of any merchant's volume.",
    "No full PAN is ever sent or stored by either side. Last 4 plus BIN plus amount plus time is the match.",
    "At-least-once is enough. Every event carries an event_id and the receipt events are idempotent on arn plus event_type, so a repeat is a no-op.",
    "Two-phase ARN. The ARN is assigned at clearing, not at authorisation. Return your own reference immediately with arn_status pending_clearing, and send arn.assigned when it lands. SyncPay sends the receipt on phase one so the cardholder sees it the same day.",
    "Return {\"found\": false} rather than an error when you have no authorisation for the keys. SyncPay retries with backoff for up to 72 hours."
  ],
  "never_send": ["full card number (PAN)", "CVV or CVC values", "magnetic stripe track data", "PIN blocks or key material", "cardholder name or contact details in the match response"],
  "read_api_live_today": {
    "base": "{base_url}/syncpay-bank-api",
    "auth": "Authorization: Bearer bank_live_...",
    "routes": ["GET /auth", "POST /merchants/lookup", "POST /transactions/search", "GET /receipts/{receipt_id}"],
    "note": "Read-only itemised receipt access for dispute evidence and merchant identity, amounts in cents, no cardholder PII in any response. Rate limits 120/min per IP and 300/min per key."
  },
  "instructions": [
    "Map the match request onto the authorisation log we already keep. Do not invent new state.",
    "Where our platform already emits something close to this shape, keep our shape and say so. SyncPay adapts to it.",
    "List every field above that we cannot produce or match on, and say why. That list is the first thing SyncPay wants on the call.",
    "Say which side we would rather host: SyncPay calling our match endpoint, or us pushing authorisations to SyncPay.",
    "Do not touch the authorisation path. The exchange runs beside it, never in it."
  ],
  "docs": "https://syncpay.au/banks.html#docs",
  "contact": "[email protected]"
}

1. Who holds what

Three parties, one payment. Each sees a different slice and the exchange is what joins them.

2. The flow, end to end

1. POS accepts the payment. Card tapped at a SyncPay-partnered POS. The POS sends its normal payment event to SyncPay. Nothing changes at the counter.
2. SyncPay ingests the transaction. Signature and duplicate checks, then the sale is written as a receipt: basket, amount, time, terminal, card BIN, last 4, processor fraud score.
3. BIN check, then match call. SyncPay checks the BIN against your range list, locally. If the card is not yours, it stops here and no call is made. If it is, SyncPay calls your match endpoint with the keys it holds.
4. You return the identifier. You find the authorisation and return the ARN, auth timestamp, last 4, scheme, your own reference and which issuer program the card belongs to.
5. SyncPay matches, then sends the enrichment. Amount, last 4 and time confirmed, ARN written onto the SyncPay receipt, then line items plus fraud signals pushed to you keyed by ARN.
6. One joined record, on both sides. You hold an itemised, fraud-scored receipt on your transaction. SyncPay holds the ARN on its receipt. Refunds and disputes follow later as events on the same key.

3. Value formats

• Integer minor units. 1150 represents 11.50 in the transaction currency. No floating point values anywhere in the payload.
• ISO 8601 UTC for every timestamp.
• Explicit currency on every message, for example "AUD". Never implied by the endpoint or the account.
• ARN is 10 to 40 upper-case alphanumerics: 23 digits on Visa and Mastercard, variable length on Amex. SyncPay normalises whitespace and case on receipt.

4. Open items to confirm

These are the questions we work through with every issuer before writing the final specification. None of them block a first call.

• BIN range list format and update cadence.
• Which side hosts the match: SyncPay calling your endpoint, or you pushing authorisations to ours.
• ARN timing: two-phase, or wait for clearing. Which auth-time identifiers you can return immediately.
• Authentication: mutual TLS or signed JWT, and the IP ranges to allowlist.
• Match tolerance on amount and time, and how you want probable matches handled.
• Sandbox access for integration testing, and a set of test BINs.
• The data-sharing agreement, and who signs it on each side.

5. Scope of work

On your side: a match endpoint over the authorisation log you already keep, a receipts endpoint that stores a JSON document against a transaction, a BIN range list, and a client credential. No change to the authorisation path. On our side: the BIN allowlist, the match client, the enrichment push with its retry queue, the refund and dispute follow-ups and the per-issuer delivery log, all built and maintained by SyncPay. The receipt lookup API is available to you from the day a key is issued.

Send us a sample authorisation record from your system and we will return the match request and the receipt it would produce, so you can see both messages before committing to anything. [email protected]

Formats on every message: integer minor units for money (1150 is 11.50), ISO 8601 UTC timestamps, explicit currency, and an ARN of 10 to 40 upper-case alphanumerics. Full card numbers are never sent in either direction.

1. Delivery

Two endpoints on your side, one on ours. SyncPay initiates the match and the enrichment push. You initiate only the optional follow-ups: the ARN once clearing runs, or every authorisation if you would rather host the matching on our side.

The one open question is which side hosts the match. Two modes, and the payloads are identical in both.

2. Match request

SyncPay to you, step 3. Every key SyncPay holds for the payment, so you can match on as many as your authorisation log supports. Null where SyncPay does not have a value, never fabricated.

{
  "sptc": "SPTC7K2M9X4A",                   // our reference, echo it back
  "card_bin": "451234",
  "card_last4": "4242",
  "scheme": "visa",                          // visa | mastercard | eftpos | amex
  "amount_cents": 1150,
  "currency": "AUD",
  "auth_time": "2026-09-10T02:14:05Z",
  "auth_time_tolerance_seconds": 120,
  "merchant_id": "MID-0041823",
  "terminal_id": "T0142201",
  "auth_code": "081224",
  "rrn": "612345678901",
  "stan": "123456"
}

3. Transaction identifier

You to SyncPay, step 4. The rail-side identifier for the authorisation you found, or found: false if you have none for those keys yet.

{
  "found": true,
  "sptc": "SPTC7K2M9X4A",
  "arn": "74567890123456789012345",
  "arn_status": "assigned",                // assigned | pending_clearing
  "auth_timestamp": "2026-09-10T02:14:04Z",
  "card_last4": "4242",
  "scheme": "visa",
  "issuer_txn_ref": "ISS-AUTH-77120934",
  "issuer_id": "PRG-CU-014",
  "network_txn_id": null,
  "match_confidence": "exact"             // exact | probable
}

No cardholder data in the response. No name, no contact details, no account identifiers. The receipt is joined to the cardholder on your side, never on ours.

4. ARN timing

The ARN is assigned at clearing, T+1 to T+3, not at authorisation. Two ways to handle the gap.

Formats on every message: integer minor units for money (1150 is 11.50), ISO 8601 UTC timestamps, explicit currency, and an ARN of 10 to 40 upper-case alphanumerics. Full card numbers are never sent in either direction.

Every message on this page lands on POST {issuer_base_url}/syncpay/receipts. Return {"received": true} within 5 seconds and do any storage work after. Delivery is at-least-once, so treat a repeat event_id as a no-op.

1. Enrichment payload and events

SyncPay to you, step 5, wrapped in the same event envelope every time.

{
  "event_id": "b7f3c2a0-1d4e-4f8a-9c6b-2e5d8a917f30",
  "event_type": "receipt.created",
  "created_at": "2026-09-10T02:14:07Z",
  "data": { }
}

• event_id is unique per event. Treat a repeat as a no-op.
• event_type is a string from the table below.
• Receipt events are also idempotent on arn plus event_type, so the same refund never applies twice.

The data block on receipt.created:

{
  "keys": {
    "arn": "74567890123456789012345",
    "sptc": "SPTC7K2M9X4A",
    "issuer_txn_ref": "ISS-AUTH-77120934"
  },
  "merchant": {
    "trading_name": "Example Cafe",
    "abn": "47312896204",
    "address": "12 Smith St, Fitzroy VIC 3065",
    "category": "cafe",
    "syncpay_merchant_id": "3f1c8e42-9b7a-4d21-8e6f-0c5a9d3b7e14"
  },
  "receipt": {
    "currency": "AUD",
    "lines": [
      { "description": "Latte",     "quantity": 1, "unit_price_cents": 550, "line_total_cents": 550, "tax_cents": 50 },
      { "description": "Croissant", "quantity": 1, "unit_price_cents": 600, "line_total_cents": 600, "tax_cents": 55 }
    ],
    "subtotal_cents": 1045,
    "tax_cents": 105,
    "tip_cents": 0,
    "total_cents": 1150,
    "paid_at": "2026-09-10T02:14:05Z",
    "receipt_url": "https://syncpay.au/r/SPTC7K2M9X4A"
  },
  "card": {
    "last4": "4242",
    "scheme": "visa",
    "entry_mode": "contactless"          // chip | contactless | swipe | keyed | on_file
  },
  "fraud_signals": {
    "processor_risk_level": "low",        // low | medium | high | null
    "processor_risk_score": 12,
    "entry_mode_flags": [ "contactless" ],
    "offline_capture": false,
    "syncpay_rating": null                // cross-network rating, when live
  }
}

• keys always carries all three references, so you can join on whichever your ledger indexes. arn is null on a phase-one push and arrives on arn.assigned.
• merchant is the merchant's real identity, not the descriptor. This is what answers "what was this charge".
• lines has no cap. A hardware store sale runs to thirty or more lines and the schema has to hold it.
• fraud_signals is what the processor scored at the point of sale, passed through unchanged. syncpay_rating is SyncPay's cross-network rating and stays null until it is live.
• receipt.refunded carries the same shape with refund_cents, refunded_at and the refunded lines. receipt.disputed adds dispute_reason and an evidence_url.

The BIN check is step 3 of the flow: after SyncPay ingests a sale from a POS partner and before it calls your match endpoint. It is what keeps the call volume bounded to your own cards rather than a merchant's full volume. The match request carries card_bin so you can route to the right issuer program on your side as well.

1. BIN range list

The BIN check runs locally on SyncPay's side, so step 3 costs no API call for cards that are not yours. You share the list once and again on change.

[
  { "issuer_id": "PRG-CU-014", "bin_start": "451234", "bin_end": "451239", "scheme": "visa",       "effective_from": "2026-09-01", "effective_to": null },
  { "issuer_id": "PRG-CU-014", "bin_start": "552310", "bin_end": "552310", "scheme": "mastercard", "effective_from": "2026-09-01", "effective_to": null }
]

• JSON array or CSV with the same columns, whichever you already produce. Six or eight digit BINs both work.
• Carry a version or an as-of date so SyncPay can confirm it loaded the latest list.
• The list is the ingest boundary. SyncPay keeps nothing for a BIN that is not on it, so adding a range later does not give you past transactions on that range.

Two credentials. SyncPay calls your endpoints on a client credential you issue. You call SyncPay, for the optional follow-up events and the receipt lookup API, on a bank_live_… key we issue. Every body in either direction is HMAC-signed on top of that.

1. Authentication and security

2. Errors

Errors return the matching HTTP status with a JSON body carrying an error string.

On your endpoints we ask for the mirror: found: false is a 200, not a 404, and a duplicate push is a 200 with received: true.

3. Privacy and billing

• Personal information. An itemised receipt is personal information under the Privacy Act once it is joined to a cardholder. The exchange runs under a data-sharing agreement, and the cardholder-facing disclosure sits with you, since the join to the cardholder happens on your side.
• Consent on the merchant side is handled by SyncPay and the POS partner. Nothing in the exchange identifies the cardholder to SyncPay.
• Billing is per successfully delivered receipt.created, per issuer program. The delivery log in section 1 is the invoice's source, and you can reconcile it against your own stored enrichments by event_id.
• Retention. SyncPay keeps the receipt permanently on the merchant's behalf. What you retain on your side is governed by your own policy and the agreement.

Use this where a cardholder or an analyst asks about a payment before the push has reached you, or if you would rather pull than receive. Every response is a hard allowlist with no cardholder PII, every call is audit-logged, and the money is in cents like every other message in these docs. Errors and rate limits are on Authentication and errors.

1. Reading receipts on demand

Separate from the exchange, and live today. A read-only API for dispute evidence and merchant identity, for the case where a cardholder or an analyst asks about a payment before the push has reached you, or for institutions that want to pull rather than receive. Everything lives under one base URL, issued with your key, so the examples use {base_url} in its place.

curl {base_url}/syncpay-bank-api/auth \
  -H "Authorization: Bearer bank_live_3f1c8e42-9b7a-4d21-8e6f-0c5a9d3b7e14"

A transaction in a search result:

{
  "receipt_id": "3f1c8e42-9b7a-4d21-8e6f-0c5a9d3b7e14",
  "sptc_code": "SPTC7K2M9X4A",
  "arn": "74567890123456789012345",
  "amount_cents": 1150,
  "tax_amount_cents": 105,
  "date": "2026-09-10T02:14:05Z",
  "payment_method": "card",
  "card_last_four": "4242",
  "processor": "square",
  "status": "settled",
  "refunded": false,
  "refund_amount_cents": 0,
  "items": [
    { "name": "Latte",     "quantity": 1, "unit_price_cents": 550, "total_cents": 550 },
    { "name": "Croissant", "quantity": 1, "unit_price_cents": 600, "total_cents": 600 }
  ]
}

• No cardholder PII in any response. The projection is a hard allowlist: no email, phone, consumer id, card fingerprint or processor customer id.
• Every authenticated call is audit-logged with route, method, sanitised query, result count and caller IP.
• Rate limits: 120 requests per minute per IP, 300 per minute per key. Over either returns 429 {"error": "rate_limited"}.
• Keep the key server side. If one leaks, mail [email protected] and we revoke and reissue it.