Separate tender paths
Choose one provider for card payments, enable Paya independently for ACH, and define any manual methods as their own customer and order workflows.
Commerce payment architecture
CMS Max Payment Gateways
Accept cards, ACH, and approved offline methods through a payment configuration your team can test and operate.
CMS Max gives merchants one active credit-card provider, a separately enabled Paya ACH path, configurable manual payment methods, sandbox controls, and post-payment workflows. The right design starts with tender ownership, credentials, settlement, refunds, exceptions, and reconciliation - not a logo list.
- One card provider
- Paya ACH
- Manual methods
- Sandbox mode
- Encrypted secrets
- Refund workflows
with CMS Max
01Choose tender paths
02Configure credentials
03Test the environment
04Accept payment
05Reconcile outcomes
Payment architecture
Design the payment system around the merchant operation.
A strong payment setup names the provider for each tender, the systems that hold credentials and transaction state, and the team responsible for every exception.
Treat credentials as production infrastructure
Use the CMS Max settings surface, the correct provider environment, least access, controlled rotation, and a named owner. Never place secrets in page content or public scripts.
Operate beyond authorization
Define settlement, capture, void, refund, cancellation, dispute, reconciliation, customer communication, support, and provider escalation before launch.
Current capability boundary
A clear control plane for payment choices.
Availability depends on the active tenant configuration, provider account, merchant approval, current provider services, checkout or form context, and tested production acceptance.
Choose one credit-card gateway
Use Authorize.Net, CardPointe, or Stripe as the active card provider. The merchant account, credentials, environment, tender rules, and production acceptance remain provider-specific.
Enable Paya for ACH
Paya is a separate ACH and bank-transfer path with its own terminal ID, customer bank inputs, provider responses, settlement behavior, and reversal workflow.
Configure manual payment methods
Add approved methods such as bank transfer, cash on delivery, or money order with customer-facing details and instructions; staff then controls the order payment status.
Switch to sandbox deliberately
Use test environments and provider test credentials to prove success, decline, timeout, duplicate submission, cancellation, void, refund, and recovery without affecting live funds.
Collect payment with the right provider
CMS Max forms currently map card collection to Authorize.Net, CardPointe, or Stripe and bank collection to Paya ACH. Form design and payment purpose remain merchant-owned.
Handle post-payment operations
Store provider and transaction context, expose only supported actions, distinguish void from refund, preserve an audit trail, communicate outcomes, and reconcile provider records.
Native payment hub: Provider accounts, approval, pricing, services, availability, settlement, disputes, and production outcomes remain subject to the current merchant agreement, live configuration, and accepted implementation scope.
Responsibility matrix
Know exactly which path owns each payment job.
The current CMS Max architecture separates the selected card provider, ACH, PayPal readiness, and manual methods. Treat each as a distinct contract.
| Workflow area | Current boundary | Production acceptance evidence |
|---|---|---|
| Credit card | Native: Authorize.Net, CardPointe, or Stripe; one active provider | Provider-approved account, valid credentials, sandbox and live tests, checkout and form acceptance, void and refund evidence |
| ACH / bank transfer | Native: Paya, enabled separately from cards | Paya terminal ID, environment credentials, account validation, payment, settlement, void or refund, and reconciliation evidence |
| PayPal | Conditional: settings and checkout configuration exist; complete backend support requires tenant validation | Client credentials, order and capture lifecycle, webhook handling, production checkout, failure, refund, and support acceptance |
| Manual method | Native merchant-configured offline workflow | Clear customer instructions, pending-payment policy, staff permissions, status updates, cancellation, aging, and reconciliation |
| Public forms | Native for supported card providers and Paya ACH | Representative form, amount rules, validation, duplicate prevention, receipts, failure handling, refunds, access, and reporting |
| Post-payment action | Provider-specific void or refund behavior | Transaction state, amount, original reference, supported action, provider response, audit log, customer notice, and ledger reconciliation |
Transaction lifecycle
Move every payment through an observable lifecycle.
The customer-facing moment is only one stage. Reliable commerce preserves context and ownership from configuration through reconciliation.
Configure
Select the tender path, environment, credentials, account, rules, permissions, and merchant owner.
Present
Show only enabled methods with clear labels, required inputs, costs, timing, and customer expectations.
Authorize
Tokenize or transmit through the approved provider flow and protect against duplicate submissions.
Record
Preserve method, provider, transaction reference, amount, response, order or form context, and audit history.
Resolve
Reconcile settlement, fulfill or hold the order, handle exceptions, void or refund when supported, and communicate.
Implementation sequence
Launch payments as an operating system, not a checkbox.
Merchant approval, provider configuration, technical acceptance, support ownership, and financial reconciliation all need evidence.
Choose methods and owners
List card, ACH, PayPal, and offline requirements by website, order type, form, location, currency, customer, and business process.
Approve provider accounts
Confirm underwriting, services, limits, tenders, settlement, reserves, pricing, disputes, fraud tools, support, and production credentials directly with each provider.
Configure protected settings
Select one card provider, configure Paya ACH or manual methods when required, choose the environment, restrict access, and document credential rotation.
Test representative journeys
Prove checkout and forms across devices, success, decline, invalid input, timeout, duplicate click, abandoned flow, cancellation, void, refund, and partial operational failures.
Train operations and support
Assign order review, reconciliation, refund approval, customer communication, dispute handling, credential ownership, incident response, and provider escalation.
Accept production evidence
Run controlled live transactions, verify provider settlement and CMS Max records, document known limitations, monitor errors, and schedule recurring reviews.
Operational ownership
Know who controls each payment outcome.
Clear boundaries make merchant onboarding, security, transaction support, refunds, disputes, incident response, and financial reconciliation faster.
- CMS Max
- Owns the CMS Max settings surface, supported payment integrations, website and form implementation, stored transaction context, application behavior, and CMS Max support scope.
- Payment provider
- Owns the merchant account, underwriting, credentials, network access, authorization, settlement, provider availability, pricing, disputes, and provider support.
- Merchant finance
- Owns provider selection, contracts, bank accounts, fees, reserves, refunds, reconciliation, chargebacks, accounting, access approval, and financial policy.
- Merchant operations
- Owns customer promises, order holds, fulfillment rules, manual methods, exception handling, support responses, staff training, and acceptance testing.
Documentation and related resources
Verify current provider and CMS Max requirements.
Payment products, APIs, credentials, merchant services, networks, rules, and supported actions change. Confirm the live account and current documentation during implementation.
Payment integration FAQ
Resolve the practical questions before launch.
Turn each answer into configured rules, representative test cases, monitoring, written ownership, and production evidence.
Which credit-card gateways can CMS Max use?
The current CMS Max card selection supports Authorize.Net, CardPointe, or Stripe, with one provider active for credit-card processing in the tenant. Provider accounts, credentials, services, and acceptance are merchant-specific.
Can CMS Max accept ACH payments?
Yes. Paya is the current native ACH and bank-transfer path and is enabled separately from the selected credit-card provider. It requires the merchant Paya terminal configuration and end-to-end testing.
Can a merchant offer manual or offline payment methods?
Yes. CMS Max can configure active manual methods with a name, details, instructions, and order. Orders remain pending until authorized staff records the payment outcome under the merchant policy.
Does sandbox mode guarantee production readiness?
No. Sandbox proves controlled test cases but cannot replace merchant underwriting, live credentials, production provider behavior, a controlled live transaction, settlement reconciliation, and operational acceptance.
Are payment credentials encrypted?
The current CMS Max settings layer marks sensitive Authorize.Net, CardPointe, PayPal, and Stripe credential fields for encrypted storage. Access control, rotation, provider security, logs, and merchant procedures still matter.
Do all providers support the same void and refund behavior?
No. Actions depend on the provider, transaction state, settlement timing, stored references, amount, credentials, and current implementation. The interface should expose only actions supported for that transaction.
Can the same payment methods be used in checkout and Maxforms?
Not automatically. CMS Max forms currently support the configured card provider family and Paya ACH; PayPal is not a current form payment provider. Test each required context independently.
Build payment confidence
Connect payment technology to an operation the merchant can trust.
Bring the provider account, required tenders, checkout and form journeys, countries and currencies, refund policy, fulfillment rules, finance process, support owners, security requirements, and launch goals.
Building Relationships with Web Developers and Marketing Agencies that want better results
The world's fastest and most SEO friendly website code.