A Android SoftPOS
Ready to tapAmount due
₦12,400.00
The merchant’s own NFC Android phone is the terminal.
A customer taps a contactless card or phone against the handset. No separate terminal to buy, carry, charge or replace.
Home / What we do
Merchant payments
Acceptance built for a market where the terminal is the bottleneck: QR at the counter, SoftPOS in the hand, proximity transfers between people, and settlement that arrives while the day is still running.
The problem
A Nigerian merchant who wants to take cards has historically needed a box. Somebody buys it, somebody carries it, somebody charges it, somebody replaces it when it is dropped. Multiply that by the millions of terminals now active across the country and the cost of acceptance stops being a percentage and starts being a logistics operation.
The merchants furthest from that logistics operation — the market trader, the pop-up, the driver, the stall on a Saturday — are the ones who most need to take a card and least able to justify a terminal.
The acceptance system
A Android SoftPOS
Ready to tapAmount due
₦12,400.00
The merchant’s own NFC Android phone is the terminal.
A customer taps a contactless card or phone against the handset. No separate terminal to buy, carry, charge or replace.
B Static & dynamic QR
Two modesPrint once for a fixed counter, or generate the exact bill when accuracy matters. Both settle into the same account.
C Proximity transfer
NearbyMove value between people in the same place without reading out or typing an account number.
D Merchant operating system
One recordTakings by method, site and staff member feed one reconciliation record instead of four disconnected exports.
Interfaces and amounts are explanatory illustrations. Product scope and commercial terms are handled privately.
Settlement
A restaurant that gets Friday’s takings on Monday is financing its own weekend. Settlement timing belongs in the product conversation from the start, not in the small print after integration.
01
Tap or scan
Card, phone or QR — whichever the customer has to hand.
02
Authorise
Routed through licensed partners with risk and fraud checks applied.
03
Confirm
Merchant and customer both see the result immediately, on their own screens.
04
Settle
Into the merchant account on the cycle agreed for the operating model.
Where it fits
Acceptance infrastructure earns its place where transaction counts are high and the cost of hardware, delay or poor reconciliation appears every day.
Restaurants & QSR
Table turns, split bills, tips and staff attribution.
Retail chains
Multiple sites, one reconciliation, per-branch reporting.
Events & hospitality
Queues that have to move, and staff handed a phone rather than a terminal.
High-transaction SMEs
Businesses whose margin lives in volume and whose cash cycle is tight.
Methods
Not a feature list — a decision table. Most businesses end up using two of these, and which two depends on how their counter actually works.
| Method | Best where | What it needs |
|---|---|---|
| Android SoftPOS | Table service, delivery, market trade, anywhere the payment happens away from a fixed till. | An NFC-capable Android handset the merchant already owns. No hardware purchase. |
| Static QR | A fixed counter, a kiosk, a stall. Printed once and left in place. | A printed code. Customer enters the amount, which suits low-value repeat trade. |
| Dynamic QR | Anywhere the amount changes and accuracy matters — restaurants, retail, services. | The merchant app to generate the code against the bill. Removes the entry error. |
| Proximity transfer | Person to person, or informal trade where neither side wants to read out an account number. | Both parties on the app. Nothing is exchanged but the transfer itself. |
Straight answers
It removes the need for a separate terminal by using a compatible NFC Android handset as the acceptance surface.
SoftPOS suits mobile or table service; static QR suits a fixed low-value counter; dynamic QR suits exact bills; proximity helps where account-number entry creates friction.
Settlement timing is part of the operating and commercial design. The correct answer depends on the method, institution and risk model, so it is confirmed privately for the specific use case.
A resilient flow distinguishes a request from a confirmed transaction, surfaces the final state clearly and gives support teams a traceable event record.
The operating agreement should name first-line support, escalation, reversals and exception ownership before payments begin.
Pricing and settlement terms depend on volume, method mix and role allocation. They are shared in a private commercial conversation.
Have a counter, settlement or reconciliation problem worth mapping?
Describe the use case