How an AI Agent Finds a Merchant's Verified IBAN

An agent knows who it wants to pay, but not where. AsterPay's Merchant Payment Endpoint turns that business identity into a verified IBAN, resolved from provable sources, with provenance and Verification of Payee, ready for SEPA Instant.

Agent payment protocols like x402 assume the agent already holds a recipient address. Real commerce does not work that way. An agent processing an invoice, restocking inventory, or paying a supplier starts from a business identity: a legal name, a VAT number, a registry entry. Turning that identity into a payable bank account, reliably, is the job of the Merchant Payment Endpoint.

AsterPay solves it the watertight way: a payee's IBAN is resolved only from sources that can be proven, each one tagged with where it came from and how strongly it is backed. The agent always knows the origin of the account it is about to pay.

Every IBAN comes from a provable source

AsterPay's Merchant Payment Endpoint (MPE) returns a payee's IBAN only when it came from a source that can be proven, and every result carries that source with it.

There are three provable sources, in descending order of strength:

1. Verified merchant registry — a merchant that onboarded and proved control of the account.
2. Signed payment manifest — the merchant's own /.well-known/pay.json, published under their domain.
3. Structured e-invoice — the IBAN read directly out of an EN16931 invoice (UBL or CII / ZUGFeRD), field BT-84, from the document the merchant themselves issued.

Then it gets verified

Resolution is only half the job. Every resolved IBAN passes full structure and checksum validation, and every API response states the verification method used (vop_method), so the agent always knows exactly which checks have run.

The strongest check is bank-side Verification of Payee (VoP), the EU-mandated name match that banks must offer on euro payments since October 2025. It confirms the account belongs to the named beneficiary. AsterPay runs VoP through its licensed settlement partner at payout; until that partner check runs, the response reports its status honestly (checksum validated, source provenance verified) and never claims a name match it has not performed.

What it looks like in one call

Resolution is free. Try the public demo merchant:

GET /v1/mpe/merchants/resolve?business_id=FI-DEMO-0001&business_id_type=demo

{
  "merchant_id": "mpe-demo-0001",
  "name": "Demo Merchant Oy",
  "country": "FI",
  "verified": true,
  "payment_endpoints": [{
    "type": "iban", "currency": "EUR", "method": "sepa_instant",
    "iban_last4": "1234", "bic": "NDEAFIHH",
    "provenance": "signed_pay_manifest",
    "confidence": "verified",
    "iban_checksum": "valid",
    "vop": { "performed": false, "status": "bank_vop_pending_partner_rollout" }
  }],
  "policy": { "auto_pay_allowed": false, "reason": "demo merchant only" }
}

Each endpoint carries its provenance, a confidence level, the checksum result, and an honest VoP status — so the agent knows exactly which checks have run before it pays. POST /v1/mpe/settle then chains the full pipeline — resolve, payee validation, the paying agent's trust check, USDC/EURC-to-EUR conversion, and SEPA Instant payout — in a single call.

The full specification, response fields, and confidence model are in our learn guide.