Support mobile sponsor checkout through slot-specific Paymail

[rohenaz]

Goal

Let a sponsor pay from a mobile wallet such as HandCash by scanning a QR code and sending to a slot-specific Paymail address, for example sponsor-silver-1@bitplan.dev.

Current limitation

Sponsor checkout is one atomic BRC-100 transaction containing both the image inscription and payment. That works with a connected browser or desktop BRC-100 wallet, but a separate mobile Paymail payment cannot construct that same transaction.

Required design

• Serve Paymail capabilities for bitplan.dev.
• Resolve a slot-specific address and show it as a mobile-friendly QR payment request.
• Correlate the received payment with the selected slot, sponsor image, backlink, and current USD quote.
• Define who constructs and funds the inscription when payment and publishing are separate transactions.
• Preserve first-valid-payment-wins behavior and handle simultaneous payments safely.
• Provide an honest recovery or refund path for a payment that cannot claim its requested slot.
• Keep the existing connected BRC-100 checkout as the initial supported path.

Acceptance

A user can select an available slot on a phone, scan or open the payment request in HandCash, pay the quoted amount, and see the correct sponsor finalized without connecting a browser wallet.

[rohenaz]

Design review complete. The current connected BRC-100 checkout should remain the preferred path because payment and inscription happen atomically.

A mobile Paymail checkout needs to be a separate merchant flow. The smallest credible design is:

• create a short-lived invoice with an exact satoshi amount and a one-time address such as sponsor-silver-1-@bitplan.dev
• bind the slot, image, name, link, quote, expiry, and refund destination to that invoice
• verify the delivered payment and BEEF, then use the same atomic slot claim as the connected-wallet path
• use a low-balance BitPlan service wallet to fund and publish the existing sponsor-inscription format
• store signed BEEF before relay so retries reuse the same transaction
• refund late or losing payments exactly once

This can reuse private, immutable Vercel Blob records for the low-volume first version; it does not require a new plan database. It does require a trusted service wallet plus a reconciliation/refund process, so it cannot be implemented safely as browser-only code.

Important compatibility finding: Paymail defines payment discovery and delivery, but not a universal QR or mobile deep-link format. HandCash compatibility must be proven with a small spike. If standards-based Paymail is not accepted by HandCash, we should either add a clearly labeled HandCash Pay adapter or support a mobile wallet that implements the standards path.

Decisions required before implementation:

1. Support standards-based Paymail, HandCash Pay, or one of them first.
2. Confirm BitPlan will operate a low-balance merchant wallet.
3. Decide whether that wallet owns the sponsor ordinal in v1.
4. Publish the refund window, response time, and support path.
5. Confirm ARC acceptance is the point at which a sponsor is shown.

The implementation gate must include mixed mobile/browser race tests, replay protection, crash recovery from stored BEEF, and a real low-value losing-payment refund test. Until those decisions are made, this issue should remain open.