Skip to content

CEP-21 Payment Method Identifier (PMI) Recommendations

Payment Method Identifier (PMI) Recommendations

Section titled “Payment Method Identifier (PMI) Recommendations”

Status: Draft Author: @contextvm-org Type: Informational

This CEP provides non-normative recommendations for Payment Method Identifiers (PMIs) used with CEP-8.

It exists to:

  • Maintain an evolving set of recommended PMIs without requiring updates to the core CEP-8 payment flow.
  • Provide naming guidance so PMI payload semantics remain unambiguous across implementations.

This CEP defines:

  • A small list of recommended PMIs for the ContextVM ecosystem.
  • Naming conventions for recommended PMIs.
  • A convention for bearer-asset PMIs that support direct settlement (-direct suffix).

This CEP does not define:

  • The syntax or semantics of CEP-8 payment notifications.
  • The payload formats for any PMI (those are PMI-defined).

Recommended PMIs are intentionally payload-scoped: they are specific enough that a client can determine what a CEP-8 pay_req contains.

PMIpay_req payload (PMI-defined)Notes
bitcoin-lightning-bolt11BOLT11 invoice stringUse when pay_req is a BOLT11 invoice (e.g. lnbc...).

Extensibility: Implementations MAY use any PMI that follows the W3C format. This CEP’s list is only a recommendation set.

To keep pay_req semantics unambiguous, recommended PMIs SHOULD:

  1. Identify the asset/network/rail family (example: bitcoin-lightning).
  2. Identify the request payload format (example: bolt11).
  3. If the payload format alone is still ambiguous, include the relevant sub-variant (example: p2tr, p2wpkh).

Avoid overly generic PMIs like bitcoin-lightning when multiple incompatible request payload standards exist.

Direct bearer settlement convention (-direct suffix)

Section titled “Direct bearer settlement convention (-direct suffix)”

PMIs that support direct bearer settlement (where a client can attach settlement data directly on a request via the direct_payment tag) SHOULD use the -direct suffix.

Example (conceptual): bitcoin-cashu-v4-direct.

This is a convention for discovery and interoperability; support is ultimately implementation-defined.