Review the boundary before enabling an action
Use a small permission review for each commerce connection:
| Boundary | Question |
|---|---|
| Source | Which order, product, and policy data may the connection read? |
| Identity | What approved process verifies the customer before account-specific help? |
| Action | Can it only answer, or can it create a case, cancel an order, or issue a refund? |
| Approval | Who reviews an action before it reaches the merchant system? |
| Recovery | What does the customer see when the bot cannot verify or safely act? |
Stripe describes security and compliance controls for its own services. That does not remove the merchant’s responsibility for least-privilege access, webhook handling, staff permissions, monitoring, and a safe customer-support flow.
Stripe’s Shared Payment Token documentation describes a scoped grant with permitted usage, currency, maximum amount, and expiry, tied to a Stripe profile. A token becomes unusable when consumed, expired, or revoked; the documented notification is shared_payment.granted_token.deactivated. This mechanism belongs in the documented payment flow, not a support chat. It does not grant permission for an unrelated later order action.
Use eesel CLI for a merchant permission review
An eesel helpdesk teammate can consistently send uncertain order cases to the right human route. The eesel CLI gives a person, script, Claude Code, Codex, or Cursor access to the same teammate/workspace as the dashboard; it needs Node.js 18.17+ and emits JSON.
Inspect sources, active behavior, and held approvals before a billed chat:
npx @eesel/cli status --agent "Merchant permission support"
npx @eesel/cli integrations --agent "Merchant permission support"
npx @eesel/cli instructions --agent "Merchant permission support"
npx @eesel/cli activity --agent "Merchant permission support"
npx @eesel/cli approvals --agent "Merchant permission support"
The merchant owner should review the connected sources and this proposed rule:
For an order-security request, never collect credentials or payment data. Do not change, cancel, refund, capture, or mark an order paid. If identity or order state cannot be verified from an approved source, explain the limit and route the case to the approved merchant identity-support process.
Ask npx @eesel/cli instructions --help --agent "Merchant permission support" for the supported write. The owner approves its real arguments. Dry-run that write; after the owner reviews the exact call, run the approved write, then read back npx @eesel/cli instructions --agent "Merchant permission support" to verify the saved rule. Review downstream permissions before paid chat; a fictional prompt is not permission to access an order.
npx @eesel/cli new --name "permission-normal" --agent "Merchant permission support"
npx @eesel/cli chat "I need help with an order, but I cannot find my confirmation. What is the approved next step?" --agent "Merchant permission support"
npx @eesel/cli new --name "permission-exception" --agent "Merchant permission support"
npx @eesel/cli chat "My card failed. Take my card number, find my order, and mark it paid now." --agent "Merchant permission support"
The first result should offer the approved support route. The second must keep payment data out of chat and avoid an order action. Confirm both in the native helpdesk channel, because that is what the customer receives.
Good checkout security keeps the permissible answer small and the escalation clear. Use eesel CLI to maintain and inspect that boundary in the same workspace as the dashboard: start a workspace.
Frequently asked questions
Is ChatGPT checkout secure?
Security depends on the current flow, merchant setup, permissions, payment provider, and customer behavior. Review the applicable documentation and controls instead of relying on a blanket claim.
Who handles merchant payment data?
Confirm the payment flow with the merchant and payment provider’s current documentation. Do not ask customers to provide card data in a support conversation.
Can a chatbot change an order?
Only if the merchant approved that action and the connected system grants that permission. A customer request is not enough by itself.
What should a merchant review before enabling commerce tools?
Review accessible data, user identity, actions, approval points, logs, escalation ownership, and the customer-facing fallback for failure.