Developers
Getting started with the Tap to Pay on iPhone SDK
You are evaluating a Tap to Pay on iPhone SDK, or a SoftPOS SDK for Android, and you want to know what building on Mypinpad actually involves before you commit engineering time to it.
What you will need
Before you write any code.
An NFC-capable device on a supported OS version
Device and OS support move as the platforms and the standards do, so coverage for your specific target devices is confirmed when you register for sandbox access rather than published here.
A standard mobile development environment
The usual toolchain your team already uses for Android or iOS development. If your team is already shipping mobile apps on that platform, you are not starting from nothing.
Credentials issued by Mypinpad
You receive these as part of onboarding and use them to authenticate your build against the platform.
Access to a test environment
Build and validate before anything goes near a live merchant.
Minimum platforms today: Android 10 or later with NFC; iOS 18.4 or later on iPhone XS or newer.
Sandbox registration gets you the environment and credentials above. A named technical contact, test merchant profiles and agreed milestones come once you move from evaluation into a commercial integration engagement — see what every route includes.
Building Tap to Pay on iPhone? Apple is part of this
This is the thing teams most often discover late, and discovering it late costs time.
Tap to Pay on iPhone requires an entitlement from Apple. Getting that entitlement is a step in Apple's own programme, obtained under a commercial agreement with Apple — it is not something Mypinpad grants, and it is not optional.
If Tap to Pay on iPhone is on your roadmap, factor the Apple entitlement into your planning from day one, alongside your evaluation of Mypinpad's SDK. It is a prerequisite, the same way a merchant account or a PCI assessment is a prerequisite elsewhere in payments. Knowing about it early is what keeps it out of your critical path later.
On the SDK route, Android and iOS are both first-class. Whichever platform you are building for, you get a comparable payment capability set — contactless card payments, mobile wallet acceptance, and PIN entry on the device screen.
The path to production
Register for sandbox access; once we have approved it, you can start evaluating.
Moving into a commercial integration engagement turns that into a defined programme: agreed milestones, test merchant profiles to build and validate against, a named technical consultant attached to your integration, and full reference documentation covering the detail your engineering team needs at each stage — rather than a set of documents and no one to ask.
This page will not put a number on how long that path takes. Every integration is different — the platform, the route you choose, and what your team is starting from all shape it — and a number here would tell you less than a conversation with a technical consultant will.
How an integration runs
Five stages, with a named technical consultant alongside you from the first call.
1
Scoping
A technical consultant confirms your route, platforms and processing model.
2
Integration
You build against the documentation, a sandbox and test merchant profiles.
3
Certification
We review your app against its MPoC obligations, and you complete scheme certification. We can run Level 3 testing for you.
4
Go-live
Production credentials, a signed card configuration and merchant onboarding.
5
Ongoing
Regular SDK releases under an update policy, and support with defined priority levels.
Ready to start building?
Register for sandbox access and evaluate against a running environment.