with one click
payment-domain-knowledge
// Payment processing domain model for Perkcord — our role in the ecosystem, provider relationships, credential ownership, PCI scope, and merchant vs platform responsibilities.
// Payment processing domain model for Perkcord — our role in the ecosystem, provider relationships, credential ownership, PCI scope, and merchant vs platform responsibilities.
| name | payment-domain-knowledge |
| description | Payment processing domain model for Perkcord — our role in the ecosystem, provider relationships, credential ownership, PCI scope, and merchant vs platform responsibilities. |
| compatibility | opencode |
| metadata | {"audience":"maintainers","repo":"perkcord"} |
Establish a shared mental model for how Perkcord relates to the payment processing ecosystem. This skill should be loaded when working on payment provider integrations, checkout flows, credential management, onboarding, or PCI-related decisions.
Perkcord is a software platform, not a payment facilitator (PayFac) and not a merchant of record. We are analogous to WooCommerce, Shopify (without Shopify Payments), or a SaaS billing tool.
| Role | Who | Example |
|---|---|---|
| Card networks | Set the rules | Visa, Mastercard, Amex, Discover |
| Issuing bank | Customer's bank (issues their card) | Chase, Capital One |
| Acquiring bank | Merchant's bank (receives funds) | Provided via the ISO/processor |
| Payment gateway | Technology that routes transactions | NMI, Authorize.Net, Stripe |
| ISO / Processor | Bundles merchant account + gateway | The "high-risk provider" a client works with, or Stripe directly |
| Merchant | Entity legally selling goods/services | The guild owner / community operator |
| Perkcord | Software platform automating checkout + entitlements | Us |
Every set of provider credentials belongs to the merchant (the guild owner), not to Perkcord.
The guild owner:
Current state: credentials are stored as deployment-level environment variables (one merchant per deployment). This works for single-tenant / white-label deployments. Target state (see #163): credentials will be stored encrypted per-guild in Convex so each guild owner can configure their own merchant account. See reference/credentials-by-provider.md for the specific values each provider requires.
PCI DSS requires anyone in the payment card chain to prove security compliance via a Self-Assessment Questionnaire (SAQ). The type depends on how much card data your system touches.
| SAQ Level | Questions | When it applies | Our providers |
|---|---|---|---|
| SAQ-A | ~22 | Card data never enters your page DOM. Entire form is hosted by the provider (redirect, iframe, or provider lightbox). | Stripe (hosted checkout), NMI (hosted URL), Authorize.Net with AcceptUI.js |
| SAQ A-EP | ~191 | Card data enters your page DOM (custom form fields) but JS sends it directly to the provider — never hits your server. | Historical Accept.js-only custom forms (not current Perkcord flow) |
| SAQ-C | ~160 | Card data passes through your server but you don't store it. | Not applicable to us |
| SAQ-D | ~329 | You store or fully process card data yourself. | Not applicable to us |
Current posture: all shipping Perkcord payment collection paths are SAQ-A. Stripe uses hosted checkout, NMI uses a hosted checkout URL, and Authorize.Net uses AcceptUI.js hosted lightbox tokenization. The old Accept.js custom-form posture is now historical context only.
Transaction fees are negotiated between the merchant and their ISO/processor. Perkcord does not set, control, or participate in these fees. We charge our own separate SaaS fee for the platform.
Typical high-risk ranges (for awareness, not something we configure):
When working on Authorize.Net subscriptions, do not treat ARB as an instant first-payment mechanism.
subscription.created alone unless the product explicitly supports a provisional-access state.createTransactionRequest / authCaptureTransaction.startDate aligned to the next billing period instead of "today".For provider-specific details (credentials, APIs, sandbox setup, tokenization approach), see:
reference/credentials-by-provider.md — What credentials each provider requires and who provides themreference/stripe.md — Stripe-specific integration detailsreference/authorize-net.md — Authorize.Net-specific integration detailsreference/nmi.md — NMI-specific integration details[HINT] Download the complete skill directory including SKILL.md and all related files