1. Developers Portal
  2. Engineering Blog

From Tap to Packet: Exploring Card Payments on Interledger

Written by Jason Bruwer

Rafiki is an open-source platform that enables Account Servicing Entities (ASEs) like banks and digital wallet providers to integrate Interledger Protocol (ILP) functionality into their systems.

Card payments are the backbone of global commerce… trusted, regulated, and deeply entrenched. Our latest exploration asks a pivotal question: how can we bring the ubiquity of card payments into the Interledger ecosystem without compromising the security and standards of the EMV model?

ILF + Cards

Card Payments Using Rafiki and ILP

At a high level, an ILP card transaction involves:

  1. Card (ICC) - EMV-compliant card with an ILP-linked wallet address
  2. POS Device - EMV kernel + ILP extensions
  3. Merchant ASE - Runs Rafiki and manages POS trust (RKI, IPEK lifecycle, compliance)
  4. Customer ASE - Runs Rafiki and manages the cardholder account
  5. Interledger Network - Routes value between ASEs

Exploring a Path from EMV Cards to Interledger

Card payments are everywhere. They are trusted, heavily regulated, and backed by decades of operational experience. At the same time, they are often locked into closed networks and bespoke integrations.

What we have been exploring is a simple question:

Starting Point: Should you build a a Kernel?

One of the earliest and most important decisions came out of conversations with our first POS (Point of Sale) manufacturing partner, who provides both the EMV kernel and a significant portion of the overall payment software stack running on the device. Because ILF’s first objective is to enable SoftPOS, we needed to choose between two approaches:

After evaluating the options, it became clear that reusing the existing kernel was the most practical and lowest-risk path to delivering SoftPOS quickly and reliably.

The C8 certification path would have meant

The C2 path means

Exploring was very clear:

C2, while perhaps less feature-rich than newer kernels, is predictable, explicit, and specification-aligned. That predictability turned out to be far more valuable than flexibility.

The immediate consequence of this choice was important:

Instead of re-implementing deeply complex, certification-heavy logic, we could focus on:

That framing shaped everything that followed.

‘Hello World’ for POS (Point of Sale): How Does a POS device become “Known”?

Before a POS can send payments into Interledger, it needs an identity. Not only a “vague” merchant identity, but a cryptographically verifiable device identity. This led us to the first new building block: POS onboarding.

POS Onboarding as a Trust Ceremony

Rather than treating onboarding as a provisioning script, we started thinking of it as a ceremony:

Onboarding

The rough onboarding flow regarding keys looks like this:

  1. The POS generates a key pair locally and sends a CSR, along with device metadata, to the ASE
  2. The ASE signs the CSR via its CA
  3. The ASE generates the IPEK (Initial PIN Encryption Key) for SRED/PIN (Secure Reading and Exchange of Data / Personal Identification Number)
  4. The ASE updates the terminal information to its database
  5. The ASE returns the signed certificate and IPEKs (TR-34) to the POS
  6. All keys are returned securely to the POS for storage

ILP Cards, POS Key Onboarding

From this point on:

This turned out to be a crucial foundation, not just for transactions, but for everything else.

Then Reality Kicks In: Keys Don’t Live Forever

Once we started thinking seriously about certification (for example, MPOC), a practical requirement surfaced very quickly:

Encryption keys must be rotated regularly (at least monthly)!

This is where things get interesting.

The POS is already running:

And the POS Manufacturer already has strong opinions (for good reasons) about:

So rather than fighting that model, we leaned into it.

A Crucial Piece Emerges: Remote Key Injection (RKI) and Key Rotation!

Instead of pushing key management into the kernel or POS logic, we introduced a new ASE-side service whose sole responsibility is key lifecycle management. Not payment processing. Not EMV logic. Just keys.

Key Rotation as a First-Class Flow

The key rotation (IPEK) flow looks like this:

  1. The POS requests a new set of IPEK keys from the ASE (via the POS API)
  2. The POS is cryptographically verified to ensure the request can be trusted
  3. A new IPEK is generated and stored at the ASE
  4. The new keys are securely returned to the POS (TR-34)
  5. The POS replaces the old keys in its secure storage with the new ones

ILP Cards, POS Key Rotation

In this model:

A subtle but important decision here:

This clean separation keeps:

At this point, the architecture started to feel “right”.

Cards Enter the Picture

With POS EMV kernel, onboarding and key rotation in place, cards themselves become almost… boring. And that is a good thing!

Card personalization follows standard EMV practice:

From an ILP perspective, the card is simply:

No special casing. No new assumptions.

The Transaction Moment

When a card is presented, everything up to this point has been preparation.

Now the familiar EMV flow kicks in:

SELECT AID
GET PROCESSING OPTIONS
READ RECORD
GENERATE AC
Optional PIN verification (Online)

See ADPU (Application Protocol Data Unit:

All sensitive operations happen:

NB: Nothing ILP-specific leaks into this phase, by design.

Crossing the Boundary: From EMV to ILP

Once the kernel has done its job, the POS shifts context. Now it is no longer “doing EMV”, it is requesting a payment. This is where the ILP terminal key issued during onboarding finally comes into play.

The POS:

Importantly, we don’t have the POS talk to Rafiki directly to authorize the transaction. Instead, we route everything through an ASE POS API:

Why?

The ASE remains firmly in control. Rafiki Does What It Already Does Well. From here on, Rafiki is on familiar ground.

It:

All the complexity stays on the backend, where it belongs.

What We Learned Along the Way

A few themes kept repeating during this exploration:

Where This Leaves Us

What is emerging is not a replacement for card payments, but an extension of them.

Interledger simply becomes the connective tissue that lets value move beyond traditional rails, securely, incrementally, and without forcing the ecosystem to start over.

As we are open source, you can easily check our work on GitHub. If the work mentioned here inspired you, we welcome your contributions. You can join our community slack or participate in the next community call, which takes place each second Wednesday of the month.

If you want to stay updated with all open opportunities and news from the Interledger Foundation, you can subscribe to our newsletter.