The short answer
There is no honest single number. A custom payment app costs whatever its hardest dependency costs: usually the device SDK, the processor integration, and certification, not the screens. A consumer checkout app, a terminal app, and a SoftPOS project can differ by an order of magnitude in effort even when the UI looks similar.
This article gives you the cost layers, three labeled example scopes, and the questions a real estimate needs. It does not publish prices, because Paying.co scopes each project from its hardware, processor, and certification requirements.
Three kinds of payment app
▸ Consumer checkout app: a phone or web app where the customer pays with a stored or entered credential. Card data usually goes through a processor SDK or hosted fields, which keeps most of the app out of card-present certification.
▸ Terminal app: an app running on a dedicated Android payment terminal that takes card-present payments through the device vendor's SDK. Hardware, SDK access, and the processor host drive the work.
▸ SoftPOS: card acceptance on a commercial off-the-shelf phone using NFC, usually under PCI MPoC (Mobile Payments on COTS) rules and processor or scheme approval. It adds attestation and monitoring requirements that the other two do not carry.
For the broader picture of how these fit together, see the Paying.co mobile app development page.
Where the budget goes
Relative weight is directional and depends on the project. It is a planning aid, not a quote.
| Layer | What it covers | Typical weight | What moves it |
|---|---|---|---|
| Discovery | Requirements, flows, hardware and processor review, risk list | Low | Unknown SDK access, unclear transaction types |
| UI and UX | Checkout, receipts, errors, accessibility, kiosk or handheld layouts | Low to medium | Screen count, branding, multi-language |
| Backend | Transaction records, user and device management, reporting, webhooks | Medium | Multi-merchant, reconciliation, existing systems |
| Device SDKs | Reader, printer, scanner, vendor SDK wrappers | Medium to high | Number of device models, vendor restrictions |
| Processor integration | Authorization, capture, void, refund, reversal, settlement | High | Processor specs, host type, number of processors |
| Certification | EMV Level 3, processor approval, MPoC or scheme requirements | High and often external | Brands, regions, contact vs contactless, retest cycles |
| Deployment | Device provisioning, remote updates, pilot rollout | Medium | Fleet size, MDM tooling, store or private distribution |
| Maintenance | OS and SDK updates, compliance changes, support | Ongoing | Vendor release cadence, number of device models |
The two layers people underestimate are certification and maintenance. See the Paying.co guides for how EMV levels fit together, and what payment technical debt actually looks like for what happens when maintenance is skipped.
Three illustrative scopes
These are hypothetical scopes written to show how assumptions shape cost. They are not Paying.co quotes and carry no prices.
| Scope A: consumer checkout | Scope B: terminal app | Scope C: SoftPOS | |
|---|---|---|---|
| Hypothetical assumption | One processor with a hosted card SDK, one platform | One Android terminal model, vendor SDK available, one processor host | Phone-based NFC acceptance, one processor, one region |
| Included | UI, backend, processor SDK integration, test environment | UI, device SDK wrapper, host integration, receipts, device provisioning | App, attestation and monitoring integration, host integration, pilot |
| Main cost drivers | Number of payment methods, refunds and disputes tooling | EMV Level 3, processor approval, second device model | MPoC evaluation path, processor and scheme approval, OS fragmentation |
| Certification burden | Low: processor-side validation | High: card-present approvals | High: MPoC plus processor approval |
| Common exclusions | Fraud tooling, chargeback ops | Hardware purchase, merchant onboarding | Merchant acquiring agreement, device enrollment support |
| Relative effort | Lowest | Middle | Highest, with longest external dependencies |
The ordering is the useful part. Adding a second device model to Scope B usually costs more than adding a screen, because every model brings its own SDK behavior and retesting.
What lowers the cost, and what an estimate needs
✓ Cost reducers: a single device model, a processor with clear specs and a working sandbox, an existing backend to reuse, a pre-certified kernel or reader, and a narrow first release.
⚠ Dependencies that stall projects: waiting on vendor SDK access, processor test credentials, certification lab or processor scheduling, and hardware lead times. These are often outside the developer's control, so ask who owns each one.
✗ Commonly excluded from a build estimate: hardware, processor fees, merchant onboarding, scheme or lab fees, and ongoing compliance work. Confirm each one explicitly.
To get a useful estimate, have these answers ready:
- Which app type: consumer checkout, terminal, or SoftPOS?
- Which devices, and which SDK versions or vendors?
- Which processor or gateway, and do you have specs and a sandbox?
- Which card brands, regions, and entry modes (contact, contactless, magstripe fallback)?
- Which transaction types: sale, refund, void, tip, pre-authorization, offline?
- Does an existing backend or POS need to integrate?
- Who owns certification coordination and fees?
- How many devices, and how will updates roll out?
If certification is the main unknown, managed EMV certification can be scoped on its own.
FAQs
Why don't you publish a price range?
Because the same screens can sit on top of very different certification and device requirements. A range without those assumptions would mislead more than it helps.
Is SoftPOS cheaper than a terminal app?
Not automatically. It avoids dedicated hardware, but it adds MPoC requirements, attestation, and wider device variation. Compare total scope, not hardware cost alone.
Does a consumer checkout app need EMV Level 3?
Typically not, since card data is handled through a processor SDK or hosted fields. Card-present terminal and SoftPOS apps are where EMV and mobile acceptance approvals apply.
What is the biggest hidden cost?
Often certification retesting and device or SDK updates after launch. Plan for both in the budget.
Next step
If you can share your target hardware, current software stack, processor, and project requirements, we can walk through a scoping conversation and flag the dependencies that will matter most. Start at the mobile app development page.
Sources
▸ PCI Security Standards Council: Mobile Payments on COTS (MPoC)
▸ EMVCo: EMV contactless and contact specifications overview
▸ Android Developers: official documentation for device and app requirements
Software executive with over three decades of experience. Focus primarily on the payment industry and FinTech technologies