Developers
Payment security, by design
SoftPOS puts a payment terminal inside a general-purpose device you do not control the way you would control dedicated hardware. That trade-off only works if the security model around it holds up to scrutiny.
This page sets out the principles Mypinpad builds on — not the mechanisms, because some of what keeps a payment secure has to stay unpublished to keep working. If you are the person who has to sign off a SoftPOS vendor rather than just integrate one, these are the three questions we expect you to ask first.
No cryptographic credentials live on the device unprotected
A device you do not fully control should not hold the credentials that would let someone impersonate your application if it were compromised. Application credentials sit in your own backend, and your server fetches them at runtime. The design keeps them off the device.
This is an architectural matter as well as a procedural one. A device is a shared, general-purpose environment — apps, operating system, user, sometimes an attacker, all with some form of access to what is on it. Anything stored there is reachable in principle. Keeping credentials off the device means a compromised device exposes a session, not a long-lived secret. Your backend, which you control and can monitor, stays the trust boundary — not the phone or tablet on the counter.
For your risk register, this is the difference between “we rotate a token” and “we reissue a credential and audit every device it touched”.
Device integrity is checked, and failure blocks payment
Before Mypinpad accepts a payment, it checks the integrity of the device it is running on. A device that is rooted, jailbroken, or running unofficial firmware fails that check. When it fails, the transaction does not go ahead.
We enforce this rather than merely recommend it, and enforcement is what matters; detecting a problem without acting on it protects nobody. A security control that flags a compromised device but still lets the payment through is a monitoring tool. One that refuses the payment is a control.
We do not publish how the check is performed. That is a deliberate choice, not an omission — publishing the mechanism would hand anyone trying to defeat it a starting point. What we will state plainly is that the check exists, that it runs before every transaction, and that failing it means the transaction is refused.
Accessibility is built into the product
Accessible PIN entry and localisation are part of the standard Mypinpad product. A customer does not have to commission them as a variant or wait for a later phase. They are available on Maple deployments.
This tends to surface late in a technical evaluation, if at all, because it is not a conventional security control. It belongs here anyway. Accessible PIN entry is a genuine security property: a cardholder who cannot complete PIN entry independently is pushed toward a workaround, and workarounds are where security models break down in practice.
For public-sector and regulated buyers, accessible PIN entry is frequently a procurement requirement in its own right, not a nice-to-have you will be asked about only if someone remembers to ask.
Where this leaves your evaluation
None of the three principles above is a differentiator dressed up as a security control.
Credentials off the device, integrity enforced before payment, accessibility as standard — these are what we would expect to see if we were the ones doing the evaluating. The detail behind each one is deliberately not public, for the same reason a lock manufacturer does not publish the pin layout.
If you want to go further than principles — test the SDK, see the integrity check in practice, work through your own risk assessment against a running environment — the sandbox is where that happens.
Access starts with a registration, and approval involves a manual step on our side. Once you are approved, onboarding is automatic.
Need more detail than principles?
If your compliance sign-off needs more than this page states, talk to us about your specific requirement.