Skip to content

docs(moonpay-commerce): merge x402 paylink flow into commerce skill#73

Open
xyz1hang wants to merge 4 commits intomoonpay:mainfrom
xyz1hang:merge-x402-into-moonpay-commerce
Open

docs(moonpay-commerce): merge x402 paylink flow into commerce skill#73
xyz1hang wants to merge 4 commits intomoonpay:mainfrom
xyz1hang:merge-x402-into-moonpay-commerce

Conversation

@xyz1hang
Copy link
Copy Markdown

Summary

Merge the MoonPay Commerce x402 paylink payment flow into the existing moonpay-commerce skill so a single skill covers both checkout surfaces:

  • Shopify storefront via mp commerce store/product/cart/checkout (Solana Pay) — existing content preserved verbatim under the original # Shop with crypto heading.
  • MoonPay Commerce x402 paylinks via mp x402 request against https://api.hel.io/v1/x402/checkout/{id} and /deposit/{id} — added under a new ## MoonPay Commerce section.

Frontmatter description and tags widened so the skill is discovered for either Shopify shopping or direct paylink payment requests. The Tips note about Solana-only support is scoped to the storefront flow only — the x402 flow supports Base, Ethereum, Polygon, Arbitrum, BSC, and Solana.

What's not included

No existing content was removed. Production-only / environment framing from the source material was intentionally omitted — only protocol, API, error, and workflow guidance was merged.

Checklist

  • skills/moonpay-commerce/SKILL.md updated with merged content
  • YAML frontmatter (name, description, tags) widened
  • Description specific about when Claude should trigger this skill
  • No changes needed to .claude-plugin/marketplace.json (skill already registered)

MoonPay Integration

The x402 flow uses the local MoonPay wallet (mp wallet list) to sign EIP-3009 / SPL token transfers against MoonPay Commerce paylinks; settlement is handled by the Helio resource server. The Shopify flow is unchanged — Helio pays gas, buyer pays the item price in USDC.

Test plan

  • Read merged skills/moonpay-commerce/SKILL.md end-to-end — both flows render cleanly
  • Verify all original Shopify commands present (mp commerce store list, cart add, checkout, etc.)
  • Verify all x402 sections present (API endpoints, ?payerAddress=, 402 structure, chains, errors, settlement, troubleshooting)
  • Confirm no production-only / test-environment phrasing leaked through

🤖 Generated with Claude Code

Add MoonPay Commerce x402 paylink payment guidance to the moonpay-commerce
skill so a single skill covers both Shopify storefront checkout and direct
paylink payments via api.hel.io.

- Existing Shopify storefront content (mp commerce store/product/cart/checkout)
  preserved verbatim under the original "# Shop with crypto" heading.
- New "## MoonPay Commerce" section covers the x402 paylink flow: api endpoints,
  payerAddress requirement, 402 response decoding, supported chains, error
  table, settlement, amount conversion, worked example, custom client notes,
  security, and troubleshooting.
- Frontmatter description and tags widened so the skill is discovered for
  either Shopify shopping or paylink payment requests.
- Solana-only note scoped to the storefront flow; multi-chain (Base, Ethereum,
  Polygon, Arbitrum, BSC, Solana) applies only to the x402 flow.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@xyz1hang xyz1hang requested a review from a team as a code owner April 28, 2026 17:22
xyz1hang and others added 3 commits May 5, 2026 16:36
…rification

Document the new POST /v1/x402/checkout/charge/{chargeToken} endpoint
(heliofi/backend#4161) that lets an agent settle the in-flight Charge
created by Shopify when the buyer selects Solana Pay at checkout — instead
of creating a parallel x402 Charge.

- Add the charge endpoint to the API table.
- Add a "Charge resume (Shopify-source paylinks)" subsection under Payment
  flow with the Solana-only constraint and the no-amount rule (price comes
  from Charge.usdcAmount).
- Add a "Verifying payment status" subsection: agents must poll
  GET /v1/charge/{chargeToken} after the 200 to confirm the PaylinkTx and
  read the on-chain txSignature, which is not returned in the 200 body for
  the charge-resume flow.
- Extend the error table with charge-token-specific cases: 404 NOT_FOUND,
  400 NON_SHOPIFY, 409 ALREADY_SETTLED, 410 EXPIRED.
- Update the pre-payment checklist and custom-client integration steps to
  include the charge status poll.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Add a "When to use" bullet and an identifier routing cheat-sheet so the
agent recognizes that a bare UUID (e.g. 6d0a1c57-3544-42e2-aa44-b654077c7529)
supplied alongside the word "charge" is a chargeToken — and should be sent
to POST /v1/x402/checkout/charge/{chargeToken}, not to /checkout/{paylinkId},
/deposit/{depositId}, or /v1/paylink/{id}/public.

The cheat-sheet covers the three ID shapes (paylink slug, depositId, UUID
chargeToken) and the fallback rule: if the charge endpoint returns
CHARGE_NOT_FOUND (404), only then try the other endpoints.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant