Android Payment App Development
Budget / Salary₹75,000–150,000
TypeFreelance project
LocationRemote
Posted50 minutes ago
A native Android application that turns the sales phone into a card terminal, embedding SumUp's Tap to Pay SDK to read contactless cards over NFC. No separate card reader.
How it fits. Two applications on one device. The Odoo POS is a Progressive Web App, built separately, and launches this app when the operator selects the card payment method.
How the flow works. A PWA cannot receive an Android activity result, so the two apps never exchange the outcome directly. The POS passes a transaction identifier by intent. The app fetches the authoritative amount from the Odoo server over its own authenticated call, runs the payment through the SDK, and posts the result back to the server — which then updates the payment line in the POS. The amount never travels in the intent, so nothing on the device can set the price.
What it does. Seven areas of work:
Provisioning and terminal identity — one-time device binding with backend service credentials, encrypted device token, terminal status screen, guarded deprovisioning
SDK lifecycle and token supply — single initialisation, a non-blocking token provider, proactive background refresh
Request validation and amount conversion — caller signature verification, payload fetch, BigDecimal conversion to minor units
Payment execution and transaction UI — starting the transaction, driving present-card and PIN screens from the SDK event stream, mapping errors to actionable operator messages
Outcome reporting — four terminal outcomes handled distinctly, written to a durable local queue and retried until the server acknowledges
Market neutrality — currency, locale and formatting driven by configuration rather than hard-coded
Diagnostics — log redaction and batched diagnostic upload
Deliverables. A production application, an attestation-compliant release build, unit tests covering the payment path, a technical readme, a provisioning procedure for IT operations, and support through the single-till pilot.
How it fits. Two applications on one device. The Odoo POS is a Progressive Web App, built separately, and launches this app when the operator selects the card payment method.
How the flow works. A PWA cannot receive an Android activity result, so the two apps never exchange the outcome directly. The POS passes a transaction identifier by intent. The app fetches the authoritative amount from the Odoo server over its own authenticated call, runs the payment through the SDK, and posts the result back to the server — which then updates the payment line in the POS. The amount never travels in the intent, so nothing on the device can set the price.
What it does. Seven areas of work:
Provisioning and terminal identity — one-time device binding with backend service credentials, encrypted device token, terminal status screen, guarded deprovisioning
SDK lifecycle and token supply — single initialisation, a non-blocking token provider, proactive background refresh
Request validation and amount conversion — caller signature verification, payload fetch, BigDecimal conversion to minor units
Payment execution and transaction UI — starting the transaction, driving present-card and PIN screens from the SDK event stream, mapping errors to actionable operator messages
Outcome reporting — four terminal outcomes handled distinctly, written to a durable local queue and retried until the server acknowledges
Market neutrality — currency, locale and formatting driven by configuration rather than hard-coded
Diagnostics — log redaction and batched diagnostic upload
Deliverables. A production application, an attestation-compliant release build, unit tests covering the payment path, a technical readme, a provisioning procedure for IT operations, and support through the single-till pilot.
Apply on Freelancer →
Project sourced from Freelancer.com. Applications happen directly on the original platform — we never collect your data.