Book a 30-min call
$ cd ~/projects/ble-contactless-payment-platform agent.shipped · in production

Tap to Pay.
No NFC Required.

BLE wasn’t built for payments. Tiny MTU, jittery latency,
no real encryption for card data. We wrote a custom GATT
profile with ECDH and AES-256-GCM on top of it.
850+ terminals across 3 countries now run on it at
99.8% success and under 2 seconds a tap.

  • Home
  • BLE contactless payment SDK & platform
Contactless payment terminal interface

BLE contactless payment SDK & platform

Industry
Fintech / Payments
Timeline
20 weeks
Key result
99.8% success, 850+ terminals
Tech stack
Swift (iOS) + Kotlin (Android) + C# (UWP), BLE custom GATT + EMV Contactless kernel, ECDH + AES-256-GCM, PCI PTS hardware, PCI P2PE, PCI DSS Level 1, HSM-backed tokenisation, Node.js, Stripe Connect

We shipped BLE payment SDKs for iOS, Android and Windows that let any Bluetooth-capable terminal take a tap. 850+ terminals across 3 countries, 99.8% transaction success, sub-2-second taps, an EMV Contactless kernel, PCI PTS-certified hardware partners, PCI P2PE end-to-end encryption, and a clean PCI DSS Level 1 audit on the back end.

A custom GATT profile fragments and reassembles payment payloads, an EMV Contactless kernel handles the card data, ECDH plus AES-256-GCM handles the BLE-layer crypto on top of PCI P2PE, HSM-backed tokenisation removes raw PAN from the device, and Stripe Connect runs settlement across currencies. Merchants keep the hardware they already have — a real alternative to Apple Tap to Pay on iPhone or Android Tap to Pay (NFC) when the existing terminal fleet can’t be swapped overnight.

SDK Engineering Approach
  • Custom GATT profile — We designed a payment-grade profile with fragmented PDU transfer, sequence numbering and retry logic to survive BLE’s tiny MTU and flaky latency.

  • Certified, not invented — ECDH for key exchange and AES-256-GCM for payload encryption over BLE on top of an EMV Contactless kernel and PCI PTS-certified hardware. PCI P2PE handles end-to-end encryption from terminal to gateway, PCI DSS Level 1 handles the back end. Standard Bluetooth pairing isn’t enough for card data — the auditor agreed.

  • One API, three platforms — Native SDKs in Swift, Kotlin and C# with identical surface and a shared test suite, so integrators write their payment logic once and run it on iOS, Android and Windows.

  • Audit-ready from day one — HSM-backed tokenisation, PCI P2PE end-to-end encryption, and full transaction logging. PCI PTS, PCI P2PE and PCI DSS Level 1 weren’t retrofits — we built for all three from week one.

What was actually hard

BLE can’t move a payment payload in one shot and its encryption isn’t good enough for card data. We had to fragment, encrypt, reassemble and still finish a tap in under two seconds so it feels as quick as NFC. Every 50 ms we shaved off came from protocol work, not UI.

Payment SDK architecture and protocol design

Project Outcome

Merchants rolled out tap-to-pay across 850+ terminals in 3 countries without buying new NFC hardware. Success rate landed at 99.8%, which matches NFC, and customers don’t notice a difference at the counter — taps still finish in under two seconds.

> <2s transaction
time
> 99.8% success
rate
> PCI L1 DSS
certified
> 850+ terminals in
3 countries
Merchant terminal processing BLE payment
Payment transaction analytics dashboard
Swift (iOS)Kotlin (Android)C# (UWP)BLE Custom GATTEMV Contactless kernelECDH + AES-256-GCMPCI PTSPCI P2PEPCI DSS Level 1HSM tokenisationNode.jsStripe Connect

“We expanded to 3 countries in 6 months using the BLE SDK. Merchants love it because they don't need new NFC hardware — any Bluetooth terminal works.”

@ Thomas G.

VP Payments — International Payment Processor

Contactless payment technology infrastructure
  • [EMV Contactless] kernel
  • [PCI P2PE] encryption
  • [PCI PTS] hardware
  • [PCI DSS L1] back end
  • [BLE GATT] payments
  • [Tap to Pay] alternative