Switch banks without changing your payment address
Move to another bank while every published link and QR code keeps working. Your payment address stays yours—not your bank’s.
The address layer money never had
Turn any URL into a universal payment address.
OPAP is an open protocol that any payment or banking app can use to discover how you prefer to be paid. Your existing bank, wallet, or payment network still moves the money. How?
Only you decide where the money arrives.
Your published URL is your OPID. Share it once—behind it, you choose where money arrives: bank, wallet, or something else in the future, without breaking payments on the sender's side.
No single bank, government, or payment network controls how you receive money.
01 / What it is
An address layer for payments.
OPAP adds the address layer payments have always lacked: a stable, public URL for getting paid. It works with infrastructure already in place—domains, HTTPS, and today's payment rails. Nothing needs to be replaced, and nobody has to wait for a network-wide rollout. Once you publish an OPAP record, any compatible payer app can use it.
Read the OPAP/1 protocol →
02 / How it works
Many address options, one link.
You publish one link—your page, exactly as it looks today. Behind it, you list the ways you accept money: a bank account, a wallet, more. Anyone who wants to pay you uses that same link, and their app picks an option you both support.
Your link never changes—not when you add an option, switch banks, or reorder them. It stays your ordinary page; your payment options sit in a small separate file alongside it, so the page can never be mistaken for your money.
For developers: the record is a static file, its location derived from the link—no server code and no content negotiation. See the protocol →
03 / Freedom technology
Your payment address should belong to you.
Today your money arrives at an account number that belongs to a bank, or a wallet address that belongs to a network. OPAP separates who you are from where the money goes—the way you keep your phone number when you switch carriers.
Receive in more than one way
Publish bank and wallet options behind one OPID so compatible payers can use a method both sides support.
Resist debanking and CBDC lock-in
Keep independent banks, wallets and payment rails behind one address. No single provider—or CBDC—has to become your only way to receive money.
04 / The political option
A small legal change can unlock enormous freedom.
Give everyone the right to register an OPID, and require public bodies to accept it as a payment instruction. The government can then use the current lawful route behind that address—a bank, wallet, CBDC, or another payment system—without owning the address or forcing one provider on the recipient.
Explore the political option →Keep your identity
Change providers, not your address
A bank may close an account, but it cannot take the OPID. Publish a new route and keep receiving through the same public address.
Keep your choice
No mandatory bank or CBDC lock-in
Multiple lawful payment routes can sit behind one OPID, so no single bank, network, or digital currency has to be the only way in.
The law does not need to reinvent money. It only needs to protect our freedom to decide how we receive it.
05 / Create your own
Publish how you get paid.
Connect your domain—and the public URLs on it—to the bank, wallet or other destination you choose. Control the domain, and you control the payment address.
Create a payment record →-
01
Choose a domain
Start with a domain you control. Add a payment tag only if you need more than one route.
-
02
Pick a destination
A bank account, digital-money wallet or another payment address.
-
03
Download the record
Protocol-valid JSON, generated entirely in your browser.
-
04
Publish and test
Host it at the supplied HTTPS path, then test it on the dedicated payment page.
06 / Adoption
How the world adopts it—without permission.
Adoption grows from the smallest working pair. Recipients publish independently, payer apps implement OPAP once, and neither side needs a direct integration with the other. Every new record is discoverable by every compatible payer, while every new payer can resolve the addresses already published. The network expands through ordinary web publishing—not a coordinated migration.
Recipients
A recipient publishes one canonical HTTPS URL for each payment purpose. The derived same-origin record route is deterministic; the examples here are local publication fixtures, not a live DNS claim.
Wallets & banking apps
Add a resolver to the payment flow: canonicalize the submitted URL, fetch only its derived record route, verify it, and re-resolve before payment.
Invoicing & checkout
Print a payable URL instead of a bare IBAN. Rotatable, verifiable and harder to forge than an account number.
Registrars & hosts
Offer payable domains as a product: publish and rotate records for customers, like they already manage DNS and certificates.
The rails change nothing. OPAP only tells payers where to find you.
Banks, wallets and chains keep settling payments exactly as they do now. Like email or HTTPS: useful for the first publisher on day one, standard once tools expect it.