The same transaction, in the same app

The moment after the payment

What you receive

Where it goes in your app

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.

Leave this empty

Name

Work email

Institution

What are you looking to do?

Send →

Prefer email? hello@syncpay.au

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 layer underneath: categorisation and merchant data.

One transaction, two versions

What accurate merchant data fixes

• The cryptic descriptor. Payment facilitator prefixes, legal entity names and terminal numbers reach your feed instead of the shop the customer walked into.
• The wrong category. A merchant's assigned category code describes the business, not the basket, so a supermarket that sells wine and electronics reports all three as groceries.
• Chain versus franchise. Two stores under one brand can settle under different entities, which splits one merchant into several in a spending breakdown.
• The stale directory. Merchant name and category tables are maintained separately from the payments they describe, so a rebrand or a move goes unnoticed for months. Here the identity is written at the sale and cannot fall behind it.

One source, not a stack of vendors

Merchant enrichment in a bank app is usually assembled: a directory vendor for the name, someone else for the logo, a third model for the category. Each refreshes on its own cycle, each infers the merchant from the descriptor rather than asking the merchant, and when they disagree your customer sees the disagreement. You are also paying three licences to reconstruct information the merchant already holds.

SyncPay is the merchant's own connection, so the identity is supplied rather than looked up. Nothing here is bought in, scraped or matched against a third-party list. It comes from the business, at the point it takes the payment.

The models read the item text, not the descriptor, which is why they can tell a bottle of wine from a loaf of bread inside the same basket at the same merchant. Nothing in that chain depends on a vendor you also have to manage.

One transaction, several categories

A single category per transaction is a modelling convenience, not a description of what happened. A supermarket basket is groceries and alcohol and household goods, and forcing it into one bucket is the reason every spending breakdown is slightly wrong.

• 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.
• Roll up or leave split, from the same record. A high-level view for the spending wheel, the full breakdown when the customer taps in. You are not choosing between them or storing them twice.
• The totals still reconcile. The line categories sum to the transaction amount, so the breakdown and the statement never disagree.
• Your taxonomy, not ours. Categories map to whatever scheme your app already uses, so nothing downstream has to be rebuilt to accept them.

What it feeds

One vendor, not two

Categorisation and itemised receipts are usually bought separately: an enrichment vendor for the merchant name and category, and a different feed, if one exists at all, for what was actually in the basket. Both are trying to describe the same purchase from two licences, on two refresh cycles, at two prices.

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

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

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.

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.

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.

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.

Why they come back

A statement line gives a cardholder nothing to return for. An itemised receipt does.

• An expense claim to file.
• A warranty to prove.
• A shared bill to split.
• A charge nobody at the table can place.

Every one of those is a reason to open your app instead of a retailer's.

1. The merchant's POS emits the sale. SyncPay reads a read-only event feed from the point of sale. Nothing changes at the counter and nothing sits in the authorisation path.
2. SyncPay builds the record. The events are replayed into one itemised record, stored against a permanent code and enriched with the merchant's real identity and the fraud signals raised on that payment.
3. Nothing is added to the card rail. The record is held against the acquirer reference number your settlement data already carries, so there is no new message type, no new field to populate and no scheme change to negotiate.
4. You resolve it over the API. Your systems call SyncPay with the merchant and that reference number, and receive the full record. That call is the only integration work on your side.

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.