01
Authorisation
The card is presented and the payment request is checked against the relevant account, card network, and configured payment environment.
Payments
What actually happens behind your transactions.
A plain-language look at the payment path — and the questions worth asking about the rate you are quoted.
The problem
The number arrives before the explanation.
A rate is quoted. Then the statement arrives and asks you to recognize a language you did not choose. A settlement appears, but the path to that number is hard to predict.
That is a familiar operating experience for a business owner: the payment works at the counter, while the cost and movement behind it still need a clearer explanation.
How processing works
Authorisation, processing, settlement.
02
Processing
The transaction moves through the configured payment path so the merchant, provider, and network records can be updated.
03
Settlement
The approved transaction is included in the movement of funds to the merchant account, with the statement showing the costs around it.
Routing architecture
Where a transaction is routed.
We look at how a configured payment environment could route transactions across its channels, providers, and operating needs. Any design is subject to the implementation and the specific setup being evaluated.
The networks and processors we work with.
A partner relationship does not by itself establish compatibility with a particular POS, terminal, platform or configuration.
Security and compliance
How payment data is handled.
We treat data handling as a calm, specific review topic. The questions belong to the proposed environment: which systems, devices, providers, people, and responsibilities are involved, and what should be documented before a decision?
Review frame
- What systems and devices sit in the payment path?
- Which responsibilities belong to the merchant, provider, or technology partner?
- What controls and documentation should be confirmed for this setup?
Cost structure
Where the cost actually sits.
We evaluate the merchant's own numbers, line by line, so the cost conversation is tied to the actual payment mix and operating setup.
The useful outcome is a clearer comparison: what the statement shows, what the proposal includes, and which questions still need an answer.
Optimisation
What a review can establish.
We can evaluate interchange categories and the merchant statement to identify what is clear, what needs explanation, and what should be compared before switching or renegotiating.
This is an evaluation of the information available for the specific business, not a promised reduction or a delivered outcome.
Read the 2% Flat Rate boundariesPayments infrastructure
Interchange optimization
Direct network routing across credit, debit, and contactless channels can be evaluated to understand available paths and fee overhead; no reduction is guaranteed.
PCI-DSS encryption
Point-to-point tokenisation is a data-handling approach that can keep card data off local infrastructure. Applicability, implementation, and any compliance position are confirmed for the proposed environment.
Transparent fee structure
A statement breakdown can identify acquirer markups, interchange surcharges, and gateway fees for evaluation. It does not by itself establish an outcome.
One defined offer
2% Flat Rate — Including Interchange
Including interchange does not mean every conceivable merchant cost, service, equipment charge, software charge or contractual obligation is included.
Next step
Start with the statement.
A free payment statement analysis gives the conversation something real to work from. For customer contact and voice workflows, explore Logical AI.
Related reading