The GoodPay Standard

The GoodPay Standard is an open specification and rulebook designed to enable seamless interoperability between Financial Institutions at a global scale. It defines how participants should implement payment flows, message structures, and operational behaviours to ensure consistency, reliability, and compatibility—across systems, borders, and existing financial standards.

Inspired by universal standards like DNS, GoodPay is not here to replace existing protocols, but to encapsulate and extend them, offering a shared language that enhances cooperation, not fragmentation.

Its goals are:

• 🌐 Global interoperability without sacrificing local relevance
• 🧩 Compatibility-first design with existing infrastructure and standards
• 🛠️ Open governance, allowing participating institutions to submit RFCs and shape its evolution
• 📜 Path to formal standardisation, with a long-term vision to become an ISO-recognised protocol

The GoodPay Standard is the foundation—not just for implementation—but for trust, collaboration, and scalable growth across the financial ecosystem.

Vision

GoodPay aims to become the DNS of Instant Payments.

Just as DNS made the internet human-usable by mapping names to IP addresses, GoodPay defines the rules and interactions that make instant payments understandable, accessible, and interoperable—across institutions, borders, and platforms.

It establishes a global standard for how users, businesses, and systems engage with instant payments, enabling a consistent experience that scales effortlessly and works seamlessly—regardless of geography or underlying infrastructure.

tip

Please check the appendix for the terminology used, or click on the tooltip ℹ️

The Identifier, The GoodIdentifier

Similar to DNS, a global standard demands an account^ℹ️ to be addressable and reachable via an identifier. The goal of the identifier is to encapsulate the address of the push payment details^ℹ️ of the account^ℹ️

The GoodIdentifier has a uniform global format. GoodPay uses a structured identifier format to uniquely address accounts for push payments and interoperability.

The format is:

<iso-currency-code>://<entity>@<issuer>.<country-code>

Components

Component	Description
<iso-currency-code>	A 3-letter ISO 4217 currency code in lowercase (e.g. gbp, eur, usd, inr). Support for digital currencies will follow ISO extensions.
<entity>	Identifier representing the account holder or logical entity (e.g. pixie.orange.cat).
<issuer>	The institution or service provider issuing the account (e.g. monzo), written in lowercase. Dot or hyphen separated if needed.
<country-code>	A 2-letter ISO 3166-1 alpha-2 country code in lowercase (e.g. gb, us, in, fr, ee).

Example

gbp://pixie.orange.cat@monzo.gb

This refers to a personal GBP account held by pixie.orange.cat, issued by monzo, held in the UK.

eur://petmarket.laopood@lhv.ee

This refers to a Euro account held by petmarket.laopood, issued by lhv, held in the Estonia.

Identifier Registry

The Identifier Registry is a database that maps account identifiers to their associated push payment details.

For example:

identifier	payment_details
gbp://pixie.orange.cat@monzo.gb	…Pixie's payment details
eur://petmarket.laopood@lhv.ee	…Pet Market's payment details

There can be multiple instances of an Identifier Registry. The GoodPay^ℹ️ product is the global identifier registry. Depending on different contexts local, or federated instances of Identifier Registries can also be hosted.

Think of it like a different between The Internet (proper noun) and internet (noun). Where The GoodPay^ℹ️ Product is the "The Internet" of identifier registries.

Global vs Local Registries

There can be multiple Identifier Registries. For example:

• A local registry operated by a regional payment system
• A federated registry across a consortium of institutions
• Or a global registry, open and interoperable by design

GoodPay serves as the global Identifier Registry, enabling cross-border, multi-institution payments with a single unified namespace.

The Internet Analogy

Think of Identifier Registries like internets: private or federated networks that allow communication within a defined boundary.

The Internet is an internet — but not all internets are The Internet.

Similarly, GoodPay is an identifier registry — but not all registries are GoodPay.

In this analogy, GoodPay is The Internet of identifier registries: The global, canonical, interoperable registry of identifiers.

The GoodURL

The GoodURL is a structured payment URL format that encapsulates all the information required to initiate a payment to a specific entity. It ensures consistency, readability, and ease of interoperability across systems.

A GoodURL looks like this:

https://<identifier-registry-host-fqdn>/pay?identifier=<good-identifier>&amount=<amount>&currency=<iso-currency-code>&reference=<reference>&transactionId=<transaction-id>

Components

Parameter	Description	Required	Implementation
<identifier-registry-host-fqdn>	Fully qualified domain name of the Identifier Registry (e.g. goodpay.dev, sandbox.goodpay.dev).	✅	Mandatory
<good-identifier>	A GoodIdentifier that uniquely identifies the recipient (e.g. gbp://pixie.orange.cat@monzo.gb).	✅	Mandatory
<amount>	Transaction amount in decimal form (e.g. 10.5, 42.123456). Supports up to 32 decimal places to allow compatibility with all major assets.	❌	Mandatory
<iso-currency-code>	ISO 4217 currency code in lowercase (e.g. gbp, eur, usd) which represents the transaction currency.	❌	Mandatory
<reference>	Free-text reference for the payment (e.g. invoice123).	❌	Recommended
<transaction-id>	Unique identifier for the transaction. May be used for deduplication or tracking.	❌	Optional

Example

https://goodpay.dev/pay?identifier=gbp://pixie.orange.cat@monzo.gb&amount=10.50&currency=gbp&reference=invoice123

Handling the URL

The identifier registry should enable participant^ℹ️ mobile applications to listen and handle these URLs on the customer smartphones.

For example:

• Apple: Handling URLs in App
• Android: Handling URLs in App

Representation

QR Code

The GoodURL can be represented and transmitted as a QR Code. With modern smartphones allowing scanning of QR Codes quite natively and triggering app launches.

The QR Code may have the participant^ℹ️ logo in the center, as long as it does not inhibit the readability of the code.

Example QR Code for GoodURL

https://hello.goodpay.dev/pay?identifier=gbp://pixie.orange.cat@monzo.gb&amount=10.50&currency=gbp&reference=invoice123

NFC

The GoodURL can also be transmitted using NFC (Near Field Communication), allowing for seamless tap-based payment initiation without relying on camera or manual input.

Transmitting GoodURL via NFC

GoodPay supports transmitting the GoodURL over the NDEF (NFC Data Exchange Format) standard. In this mode, the URL is encoded as a well-known URI record, which can be read by most modern smartphones without requiring custom apps.

Coming Soon

APDU-based transmission for secure element-backed or card emulation use cases is coming soon, enabling tighter hardware integration with current smartphone harware.

Writing GoodURL to Passive NFC Tags

The GoodURL can be written to NFC tags (e.g. cheap sticker tags or keyfobs) as a URI-type NDEF record. These tags are ideal for use cases like static merchant identifiers at a shop counter or product-linked payments.

• ✅ Compatible tag types: NFC Forum Type 2 and Type 4 tags (e.g. NTAG213, NTAG215, NTAG216)
• ✅ Cheap stickers (e.g. NTAG213): ~144 bytes of usable space—enough for most GoodURLs
• ✅ Tags can be passive and unpowered, suitable for low-cost deployment

Most modern smartphones can both read and write to these NFC tags: • iOS (iPhone 7 and above): native reading; writing supported via apps • Android (most mid-range and above): full read/write support via OS or app APIs

Example interaction:

1. Customer taps phone on a counter sticker
2. NFC reads the GoodURL from the tag
3. Participant app is launched and initiates the payment

Writing GoodURL to Active NFC Tags

note

Coming soon

The Payment Rails

The GoodPay Standard is intentionally agnostic to the specific payment rails used for fund movement and settlement. However, it enforces a clear set of requirements to ensure speed, reliability, dispute safety, and fee fairness across implementations.

Payment rails must meet certain minimum criteria to be considered GoodPay-compliant. Where native support is lacking, fallback services that comply with the GoodPay spec may be used. The standard ensures that users and institutions can rely on a consistent quality of service, regardless of the underlying rail.

Requirement	Level
The transaction must complete (success or failure) within 30 seconds.	Mandatory
The rail must support a dispute resolution mechanism relevant to the transaction type (e.g. goods not received). If not, a GoodPay-compliant external provider must be used.	Mandatory
The rail must support a confirmation of payment completion. If not, a GoodPay-compliant resolution service must be used.	Mandatory
Transaction fees must not be proportional to the amount (e.g. percentage-based fees like 2% are disallowed). Fixed-fee or tiered models are acceptable.	Mandatory
Funds should settle into the payee’s account immediately after transaction completion.	Recommended
Ability to enrich payer/payee identity with metadata such as logo, picture, address, or display name.	Optional

GoodPay Services (Coming Soon)

For rails that do not natively support the required mechanisms, GoodPay will offer specifications for the following fallback services:

GoodPay Dispute Resolution Service

A neutral, protocol-driven resolution system for handling disputes in a transparent and standardised manner.

GoodPay Transaction Resolution Service

A canonical source of truth to confirm transaction completion in schemes where native confirmation isn’t supported.

GoodPay Enrichment Service

A standardised metadata layer to enrich transaction payloads with logos, names, and other context about participants.

note

These specs are under development and will be published in upcoming revisions of the GoodPay Standard.