The program
A listener in the terminal. Rules in the cloud.
The programme sits inside the terminal as its own application. The acquirer's payment application exposes a small set of event hooks during the transaction; the rules resolve in our cloud, and the payment application keeps control of the transaction throughout.
Three journeys, three moments
- Enrolment
- The terminal offers to register the card. The cardholder accepts or skips; a profile exists only if they accept. After authorisation · amount not involved
- Accumulation
- Points or stamps are credited against the registered card, on the purchase that is being completed. After authorisation · amount not involved
- Redemption
- The available reward is shown, the cardholder accepts it, and the amount is adjusted before the transaction goes for authorisation. The cardholder authorises the adjusted amount. Before authorisation · amount adjusted
A phone number is a separate, optional step the merchant can switch on. With it on, the cardholder can still enrol with the card alone.
How the customer is recognised
Identification runs on a token the acquirer builds from its own key or vault. The same physical card always yields the same value, on every terminal and at every merchant, which is what makes the programme work across a whole acceptance network rather than one store at a time.
The token is not reversible without the acquirer's key, carries no fragment of the card number, and is never a BIN. The acquirer's key is never shared with us. On our side the identifier is salted and hashed again, with a salt dedicated to that acquirer, before it reaches storage.
Scope and isolation
- Never crosses
- Card number, track data, CVV, PIN.
- Payment flow
- Unchanged. The programme does not authorise, clear or settle, and it does not decide the payment.
- Between merchants
- No customer data moves between merchants. Aggregates are anonymised.
- Data residency
- Single region, Frankfurt (eu-central-1), with no cross-region replication.
The data that puts a system in PCI scope does not enter ours. It is verifiable field by field against the integration data contract.
Integration
- Terminals
- Any Android terminal. A single build, with no per-model variant and no hardware homologation. Prior work on Ingenico, Verifone, PAX, Castles, Sunmi and Urovo devices.
- Communicator SDK
- A typed Kotlin dependency compiled into the acquirer's payment application. Ships through the acquirer's own release cycle.
- Direct App-to-App
- The same messages sent as plain broadcasts, with no dependency in the payment application. For fleets where a third party maintains that application.
- Acquirer API
- REST, for onboarding and administering merchants, branches and terminals.
Both integration paths use the same messages. The choice is an engineering one, not a difference in what data moves.
The commercial model
The acquirer prices and bills the programme to its merchants as a monthly software subscription, keeps its margin, and remits the net fee. There is no implementation charge and no per-transaction fee on the acquirer's payment economics.