1. Developers Portal
  2. Engineering Blog

From Tap to Packet: Exploring Card Payments on Interledger

Written by Jason Bruwer

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 (standard EMV flow/state machine for an ICC/contactless transaction)?

ILF + Cards

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.

Table of Contents

  1. Card Payments Using Rafiki and ILP
  2. Exploring a Path from EMV Cards to Interledger
  3. Starting Point: Should you build a Kernel
  4. ‘Hello World’ for POS (Point of Sale): How Does a POS device become “Known”?
  5. The Transaction Moment
  6. Conclusion, Where This Leaves Us
  7. What is next for ILF and Cards?
  8. References
  9. Glossary of Terms

Card Payments Using Rafiki and ILP

At a high level, an ILP card transaction involves:

  1. Card (ICC) - EMV-compliant card with an Open Payments enabled 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: What if card payments could naturally flow into Interledger without breaking EMV, without replacing kernels, and without weakening the security model everyone already relies on? This post is a walkthrough of that exploration - not a final specification, but a journey through the design decisions, trade-offs, and the emerging shape of an ILP-enabled card flow built around Rafiki, existing EMV kernels, and a small set of new supporting services.

Starting Point: Should you build a Kernel?

In the world of card payments, a kernel is the core software component within a POS terminal that manages the complex interaction between the payment card (the chip) and the terminal. It handles the EMV protocol logic, data-exchange, and cryptographic processing required to authorize a transaction. Essentially, it is the “brain” that knows how to speak “chip card” securely and according to global standards.

With the kernel being the “brain” of the POS, it quickly became clear that our first major design decision would revolve around which kernel approach to build on. 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: ILF does not need to develop an EMV kernel.

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 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)

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:

  1. Assembles transaction data
  2. References the cards wallet address (Customer ASE)
  3. Signs the request with its ILP key (Merchant ASE)
  4. Sends it to the Customer and Merchant ASE

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:

Conclusion, 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.

What is next for ILF and Cards?

References

Glossary of Terms

TermDescription
ACApplication Cryptogram (generated during EMV processing, e.g., via “GENERATE AC”)
ADPU / APDUApplication Protocol Data Unit (smart card command/response format; commonly spelled APDU)
AIDApplication Identifier (identifies an EMV application on a card; used in “SELECT AID”)
APIApplication Programming Interface
ASEAccount Servicing Entity (e.g., a bank or wallet provider running/operating accounts and services)
CACertificate Authority (signs certificates/CSRs)
CIContinuous Integration (automated build/test pipeline)
CSRCertificate Signing Request
C2 / C8EMVCo kernel/specification “level” referenced in the article (e.g., choosing an existing certified kernel vs. a newer certification path). These refer specifically to EMV Contactless Kernel specifications.
EMVCard payment standard originally from Europay, Mastercard, Visa
EMVCoThe organization that maintains and publishes EMV specifications (EMV Cooperation)
HMACHash-based Message Authentication Code
HSMHardware Security Module (secure key generation/storage/crypto operations)
ICCIntegrated Circuit Card (chip card; in EMV contexts, the card itself)
ILPInterledger Protocol
IPEKInitial PIN Encryption Key
JSONJavaScript Object Notation
MPOCMobile Payments on COTS (COTS = Commercial Off-The-Shelf; a payments/security certification context)
PANPrimary Account Number (card number)
PINPersonal Identification Number
POSPoint of Sale
RKIRemote Key Injection
SDKSoftware Development Kit
SoftPOSSoftware Point of Sale (POS implemented primarily in software)
SREDSecure Reading and Exchange of Data
TMKTerminal Master Key
TR-34ANSI TR-34 key exchange / key block standard used for secure key distribution (often referenced in payments key injection)
URLUniform Resource Locator

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.