Developers
SoftPOS integration routes
Three routes onto the platform, differing in how much of the payment experience you build yourself. The compliance-bearing part — card read, PIN entry, transaction — is ours on every route. What changes is how much of the surface around it you own.
None of the three is the right route in the abstract. The right one matches what you are building and who it is for. This page sets out what each costs you, in effort and in control.
SDK
Most control, most integration workEmbed Mypinpad's SoftPOS SDK directly inside your own application. Your team owns the app, the interface and the flow around the payment moment; the SDK handles the parts that carry the security and compliance burden — reading the card, entering the PIN, completing the transaction.
What you get
The payment experience looks and behaves exactly like the rest of your product. No visual seam, no hand-off to another app.
What it costs
Your development team does the integration work — understanding the SDK's interfaces, building the surrounding screens, and taking on testing as part of your own release process.
Who it suits
Teams with the engineering capacity to do that work and a strong reason to, typically because the payment moment has to feel native to a product your users already know. The route for a fintech or acquirer building payment acceptance as a first-class feature of its own app, not a bolt-on.
Wattle
A white-label middle groundA white-label acceptance application built on the Mypinpad platform — Wattle on Android, iWattle on iOS, licensed separately. Choosing this route means choosing per platform, not one product that spans both. Instead of embedding an SDK, you take an application that already does the acceptance work and put your brand on it.
What you get
You own the brand and the surface your merchants and their customers see — logo, colours, identity. You do not own, and do not need to build, the payment plumbing underneath it.
What it costs
Less integration work than the SDK route, since you are not building the payment flow from scratch. You still configure and deploy the branded application, and you give up some control over exactly how each screen behaves — you are working within Wattle's existing flow, styled as yours.
Who it suits
Organisations that want less build work than a full SDK integration, but still need the acceptance experience to read as unmistakably theirs — acquirers and PSPs rolling out branded acceptance apps to a merchant base, without building and maintaining a payment app from the ground up.
Acacia
Least effort, designed to stay out of the wayA deeplink acceptance application your app calls app-to-app — Acacia on Android, iAcacia on iOS, licensed separately. Acacia is built to be as close to invisible as a payment application can be: it handles the least necessary to take the payment, then hands control straight back. The major screens stay in your app.
What you get
The least integration effort of the three, without giving up your product. Your app keeps the basket, the order, the receipt and everything around them — Acacia appears only for the part that has to be handled inside a validated payment application, and gets out of the way.
What it costs
The payment moment itself is Acacia's, not yours. That is the part carrying the security and compliance burden, so it is the part you were least likely to want to build.
Who it suits
Applications where payment is one function among many and the product is everything around it — point of sale, field service, ordering, delivery. You keep the app your users know; Acacia takes the transaction and returns.
Choosing between them
Ask how much of the payment surface needs to be yours, against how much engineering time you have to spend building it.
SDK gives the most control, for teams with capacity to build it. Wattle is the middle ground — your brand, without building the underlying flow. Acacia takes the least effort and stays out of your product, handling only the payment moment itself.
Organisations across Mypinpad's customer base use all three, often for different products within the same business.
Evaluating, then integrating
Whichever route you choose, sandbox access works the same way: you register, and once we have approved your access you can start evaluating.
Moving from evaluation into a commercial integration engagement adds the following. These come with that engagement, not with sandbox registration.
A defined path to production
Agreed milestones rather than an open-ended integration.
Test merchant profiles
Build and validate against realistic conditions before going live.
A named technical consultant
Integration questions go to a person who knows your deployment, not a queue.
Full reference documentation
The detail your engineering team needs once you are building.
On the SDK route, Android and iOS are both first-class — contactless card payments, mobile wallet acceptance, and PIN entry on the device screen, with the same transaction types on both platforms. One SDK evaluation, one decision, and both operating systems are covered. Wattle and Acacia ship as separate Android and iOS applications, licensed separately per platform.
Not sure which route fits your product?
Tell us what you are building and we will tell you which route makes sense.