Most payment platforms hand you a dashboard and a support queue. We took a different route. Paying.co puts the same parsing and decoding logic our team relies on during certification directly in your browser — free, client-side, and no sign-up. These are the utilities that come out of the daily work behind 131+ EMV Level 3 certifications.
This is a tour of what's available at paying.co/tools, why every tool runs entirely on your device, and how those browser utilities pair with open-source SDKs so the path from inspecting a payload to shipping an integration is short.
The principle: nothing you paste leaves your device
Card-present data is sensitive. So every tool on the page is built the same way → it runs entirely client-side. Nothing you paste is transmitted to a server.
That means you can paste real TLV, real APDUs, real PANs, real ISO 8583 messages during engineering and certification work without routing production values through someone else's backend. It's a deliberate design choice, and it's the reason these tools are safe to reach for mid-certification rather than only on synthetic data.
The six tools
⌗ EMV TLV Parser & Builder
Paste BER-TLV hex from a chip or contactless transaction and read it as a labeled, nested tag tree — or work the other direction and assemble TLV from a tag and value, with the length computed for you. Spaces, colons, and 0x prefixes are all ignored on input.
This is the workhorse, and it goes well beyond a flat hex dump →
◆ Several hundred EMVCo and common proprietary tags, each labeled by name
◆ Bitwise decoding for the tags you actually need to read at the bit level — AIP (82), TVR (95), TSI (9B), CID (9F27), Terminal Capabilities (9F33), TTQ (9F66), CTQ (9F6C)
◆ DOL expansion for CDOL1, CDOL2, PDOL, DDOL, and TDOL — showing exactly which data each list requests
◆ ASCII rendering for text tags like Application Label and Cardholder Name, plus date and currency humanizers
Under the hood it understands structure the way the spec does → EMV data is encoded as BER-TLV, where every element is a Tag, a Length, and a Value. The constructed bit (0x20) marks objects that nest more TLV inside, like the FCI template (6F) or the Read Record template (70), and the parser walks that hierarchy recursively so a GPO response or PPSE record unfolds into a tree you can actually read.
⌕ AID / RID Decoder
Paste an Application Identifier or RID and identify the card scheme, the registered application provider, and the proprietary extension that follows it.
An AID names the payment application selected on a chip card, and it splits into two meaningful parts →
◆ RID — the first 5 bytes (10 hex), a value assigned through ISO/IEC 7816-5 that identifies the scheme or provider. Example: A000000003 = Visa
◆ PIX — up to 11 bytes that follow, provider-defined, distinguishing products like credit, debit, or a regional variant. Example: 1010 = Visa credit/debit
◆ Category — the leading nibble of the RID signals the registration category (A = international)
This is the tool for the moment you're handed an AID and need to know whose application you're actually talking to — and it's quietly essential to application selection, since a single card often carries several AIDs (a global credit application alongside a regional or common-debit one) and the terminal picks one at selection time.
⌸ APDU Inspector
Paste a command or response APDU and read it field by field — CLA, INS, P1, P2, Lc, data, Le, and the SW1-SW2 status word with its ISO 7816 meaning. Common EMV commands are recognised by name, so SELECT PPSE, GET PROCESSING OPTIONS, and READ RECORD show up as themselves rather than raw hex.
ISO/IEC 7816-4 defines the APDU as the unit of exchange between a smart card and reader. The header carries the essentials →
◆ CLA — class of instruction (00 ISO, 80 proprietary)
◆ INS — instruction code (A4 SELECT, B2 READ RECORD, AE GENERATE AC)
◆ P1, P2 — instruction parameters
◆ Lc — length of command data, then the data itself
◆ Le — maximum expected length of response data
Where the inspector earns its keep is the status word. It'll tell you that 9000 is a clean success, that 61xx means the card has more data waiting on a GET RESPONSE, and that 6Cxx means your Le was wrong and needs re-issuing — the small distinctions that decide whether a terminal flow moves forward or stalls.
→ paying.co/tools/apdu-inspector
✓ Luhn / PAN Validator
Check a Primary Account Number against the Luhn mod-10 checksum, identify the issuing network from the IIN, and compute the correct check digit for a partial number. Spaces and dashes are ignored, so you can paste a PAN however it's formatted.
The network detection reads the leading digits — the Issuer Identification Number, historically the BIN — and maps them to a scheme by prefix and length →
◆ Visa — starts with 4
◆ Mastercard — 51-55 and 2221-2720
◆ American Express — 34, 37
◆ Discover — 6011, 64-65, 622126-622925
◆ Diners Club — 300-305, 36, 38-39
◆ JCB — 3528-3589 · UnionPay — 62
Two honest caveats the tool states plainly, and they matter → it identifies the network, not the specific bank, since there's no live BIN lookup against an issuer database. And a valid Luhn only proves the number is well-formed; it says nothing about whether the account exists or can be charged. Use test card numbers where possible.
→ paying.co/tools/luhn-validator
⊞ ISO 8583 Decoder
Paste an ISO 8583 message and read its Message Type Indicator, expand the primary and secondary bitmaps, and see exactly which data elements the message declares — each labeled by field name.
A little context on why this one is shaped the way it is → ISO 8583 is the messaging standard that moves an authorization, reversal, or settlement record between a terminal, an acquirer, a network, and an issuer. Every message opens with a four-character MTI describing its version, class, function, and origin, followed by a bitmap flagging which of the 128 possible data elements are present, then the elements themselves in order.
The decoder reads that structure for you →
◆ The primary bitmap is 64 bits covering fields 1 through 64
◆ If field 1 is set, a secondary bitmap follows, covering fields 65 through 128
◆ Each set bit means that data element is present in the message body
One deliberate limit worth calling out: it identifies the MTI, expands both bitmaps, and lists every present field with its standard name, but it does not split field values. Data-element formats vary by network and acquirer specification, and reliably parsing values requires the specific format table. The bitmap and field names are universal; the values are not. So the focus stays on structure and which elements are declared.
→ paying.co/tools/iso8583-decoder
⟨⟩ Repositories
Where the browser tools help you inspect and debug, the repositories help you ship. Public SDKs and code libraries for building on our products — open source on GitHub under the PayingCo organization, free to use.
→ paying.co/tools/repositories
From inspecting a payload to shipping an integration
The tools decode and validate what you're already working with. The SDKs give you typed, ready-to-use clients for the products behind Paying.co — so the distance between "I understand this payload" and "I've shipped the integration" is genuinely short.
askpay-sdks
SDK libraries for Ask by Paying.co — white-label payment requests over QR and SMS for ISOs and VARs.
◆ Languages → C#, TypeScript, Go, PHP, Python
◆ Product → ask.paying.co
landed-sdks
API and SDK libraries for Landed.net, the AI-powered page builder. Publish, manage, and automate pages from code.
◆ Languages → TypeScript, PHP, Python, JavaScript
◆ Product → landed.net
puny-sdks
API SDK for Puny.io — security-first link shortening and capsules. Shorten, brand, and expire links programmatically.
◆ Languages → Java, TypeScript
◆ Product → puny.io
Everything here is meant to be bookmarked and returned to. No login, no setup, no cost. Browse them all on the PayingCo GitHub organization.
Want a library we don't publish yet?
We build SDKs and reference integrations as part of client engagements across every major terminal and acquirer. If you need a client in a language — or for a platform — we haven't released publicly, that's exactly the kind of thing a certification engagement produces.
And if you're integrating with an acquirer host directly, that's the core work: Paying.co builds and certifies against acquirer and network specifications regularly, running the full certification lifecycle across the US, Canada, LATAM, the Caribbean, and Europe.
Start building
The tools are free and waiting. The team behind them is one message away.
→ Talk to our sales team: paying.co/contact · sales@paying.co
→ Book a meeting directly: meet.paying.co
→ Open the tools: paying.co/tools
Payments are complex. The tooling around them doesn't have to be.
Paying.co (Mojave Payment Technologies, LLC) is the payment engineering team behind 131+ EMV Level 3 certifications, building API-first payment infrastructure, open-source SDKs, and free, client-side developer tools for the engineers shaping modern commerce.