AI-assisted integration

Use the SiXPay public skill with a coding agent when you want it to implement a payment flow in an existing merchant application. The skill gives the agent the checkout-session contract, SDK UI integration, subscription rules, and webhook requirements without exposing merchant credentials in the prompt.

Give the agent the SiXPay skill

Provide this URL to the agent and ask it to read or install the skill using its own skill workflow:

https://sixpay.xyz/skills/integrate-sixpay

Then give the agent one scoped prompt below. Replace every <...> placeholder with your own information. Do not include a Merchant API Key, signing key, webhook secret, or customer data in the prompt. Put credentials in the application’s server-side secret manager instead.

Ask the agent to inspect the existing order or subscription code before editing it. The prompts assume an existing merchant backend and should result in a server-authoritative integration.

Checkout prompt

Use this for a one-time purchase or invoice. It directs the agent to create a Checkout session on the merchant server and open the hosted UI with browser-safe session credentials.

Read and follow the SiXPay merchant integration skill at
https://sixpay.xyz/skills/integrate-sixpay.

Add a production Checkout flow to this application.

Context:
- Framework and runtime: <for example, Next.js 15 with a Node API route>
- Existing order creation location: <file, route, or service>
- Checkout entry point: <page or component>
- Merchant tenant ID source: <server environment variable name>
- Merchant order identifier: <existing order.id field>
- Webhook endpoint: <existing route, or say "create one">

Requirements:
1. Preserve the existing order model and create the merchant order before a Checkout session.
2. On the server, use the Merchant API Key with checkout_session:create to create a SiXPay Checkout session from server-authoritative line items.
3. Return only id, checkoutToken, and expiresAt to the browser. Never expose the Merchant API Key or place checkoutToken in a URL, local storage, analytics, or logs.
4. Use @sigworld/sdk-ui and SiXPayCheckoutModal (or createSiXPayCheckout for a non-React page) with checkoutSessionId and checkoutToken only.
5. Add signed webhook verification, replay protection, idempotent event processing, and order reconciliation by order.intentId and order.merchantOrderId.
6. Do not mark an order paid from a browser callback. Use the verified webhook as the payment authority.
7. Add focused tests for the server endpoint and webhook state transition, and report the files changed plus any configuration I must supply.

Continue with Checkout sessions, SDK UI checkout, and Webhooks when reviewing the generated changes.

Subscription prompt

Use this for recurring ERC-20 payments. A subscription product must be published in the Merchant Console before the agent can create a session or render the hosted subscription UI.

Read and follow the SiXPay merchant integration skill at
https://sixpay.xyz/skills/integrate-sixpay.

Add a production recurring Subscription flow to this application.

Context:
- Framework and runtime: <for example, Remix with a Node server>
- Existing account and entitlement model: <file, route, or service>
- Subscription entry point: <page or component>
- Published subscriptionProductId source: <server configuration or product record>
- Merchant subscription order identifier: <existing pending order.id field, or "none">
- Webhook endpoint: <existing route, or say "create one">

Requirements:
1. Use the published SiXPay subscriptionProductId. Do not substitute an on-chain subscription ID, plan ID, or transaction hash.
2. Render SiXPaySubscriptionModal from @sigworld/sdk-ui. Use the product ID for the normal hosted flow; create a server-side subscription checkout session only when the application needs to associate a pending order or customer reference.
3. Keep the Merchant API Key on the server. If a subscription session is used, return only id, checkoutToken, and expiresAt to the browser and keep the token transient.
4. Treat onComplete only as transaction submission. Verify signed webhooks and process each webhook id once.
5. Create or activate the merchant-side record from subscription.created; grant or extend access only from subscription.payment_succeeded; pause or revoke access for failed, cancelled, or expired events according to the existing policy.
6. Do not grant recurring access from browser state or from an unconfirmed transaction.
7. Add focused tests for webhook idempotency and entitlement changes, and report the files changed plus any Console configuration I must supply.

Continue with Subscription payments, Subscription SDK UI, and Subscription webhook events when reviewing the generated changes.

Review the result

Before deploying agent-generated code, verify that the implementation has all of the following:

A Merchant API Key is read only by server-side code.
Browser code receives only the short-lived checkout credentials it needs.
Checkout uses SiXPayCheckoutModal or createSiXPayCheckout; recurring payments use SiXPaySubscriptionModal.
Webhook signatures, timestamp/replay rules, and duplicate-event handling are enforced before a local state transition.
Payment and subscription entitlements are driven by confirmed webhook events, not client-side success states.

The agent can use the published skill bundle directly when its environment does not support skill installation.

Overview

Checkout

Subscriptions

Webhooks

SDK & Integration

Operations & Guides

Checkout Reference

Subscription Reference

AI-assisted integration

Give the agent the SiXPay skill

Checkout prompt

Subscription prompt

Review the result

​Give the agent the SiXPay skill

​Checkout prompt

​Subscription prompt

​Review the result

Give the agent the SiXPay skill

Checkout prompt

Subscription prompt

Review the result