Acknowledge the current boundary
No native Payarc package, settings class, server provider, route, or feature test is present in the current CMS Max application, so the connection starts as custom engineering.
Custom payment integration scope
Payarc for CMS Max eCommerce
Connect Payarc through a merchant-specific implementation with explicit security, transaction, event, and support boundaries.
The current CMS Max application does not include a native Payarc payment provider or settings package. CMS Max can evaluate a custom Payarc connection against the merchant account and current PAYARC APIs, then scope only the card, ACH, hosted checkout, refund, webhook, reporting, and operational flows that will be implemented and accepted.
- Merchant API tokens
- Sandbox + production
- Hosted or tokenized UI
- Webhook events
- Void + refund scope
- Acceptance testing
with CMS Max
01Discover account
02Choose integration mode
03Implement transaction
04Verify events
05Accept operations
Payment architecture
Scope Payarc from the current API contract, not a generic gateway promise.
PAYARC documents card, ACH, hosted fields, hosted checkout, voids, refunds, and other services. A CMS Max project should include only the merchant products, endpoints, and operating flows selected and tested for that tenant.
Choose one secure capture model
Evaluate PAYARC hosted checkout, hosted fields, or another current provider-supported tokenized flow against experience, PCI scope, accessibility, devices, and merchant account eligibility.
Design for events and recovery
Verify provider notifications, make transaction changes idempotent, map states to CMS Max, preserve references, monitor failures, and document safe replay and reconciliation.
Current capability boundary
Convert provider options into one supportable merchant workflow.
No capability below is native CMS Max functionality until it is included in the signed scope, implemented, tested in the merchant environments, and accepted for production.
Merchant and partner credentials
PAYARC provides account-specific API credentials and environment-specific keys. Define who owns issuance, storage, access, rotation, revocation, and support.
Hosted or tokenized payment UI
Select a current provider-supported method that limits sensitive data exposure while meeting the CMS Max checkout design, accessibility, device, and customer requirements.
Server transaction lifecycle
Scope create, authorize, capture, sale, amount verification, currency, customer and order context, idempotency, errors, and provider reference storage.
Authenticated asynchronous updates
Choose required webhooks or provider notifications, verify authenticity, tolerate retries, handle out-of-order events, monitor failures, and map states once.
Void and refund operations
Implement only approved full or partial actions with transaction eligibility checks, permissions, audit history, customer communication, and finance reconciliation.
Merchant-owned production process
Document provider portal lookup, settlement, disputes, support, reporting, incident response, access review, credential rotation, and controlled integration changes.
Custom scope required: 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
Turn a custom gateway request into an acceptance contract.
Discovery should resolve the provider product, CMS Max surface, sensitive-data path, transaction states, event model, and merchant operation before engineering begins.
| Workflow area | Current boundary | Production acceptance evidence |
|---|---|---|
| Merchant account | PAYARC and merchant | Approved products, countries, currencies, card or ACH services, limits, settlement, fees, disputes, users, support, sandbox and live credentials |
| Payment interface | PAYARC hosted or tokenized component plus CMS Max experience | Chosen product eligibility, data path, HTTPS, accessibility, responsive behavior, validation, errors, cancellation, provider outage |
| Server API | Custom CMS Max integration and PAYARC API | Authentication, amount and currency verification, transaction creation and capture, idempotency, timeouts, retries, references, secure logs |
| Events | PAYARC notification service and custom CMS Max handler | Authentication, subscribed events, state map, retries, replay protection, out-of-order handling, dead-letter recovery, monitoring |
| Post-payment | Custom CMS Max operations plus PAYARC state | Void and refund eligibility, amount policy, permissions, provider result, order update, customer notice, audit trail |
| Finance and support | Merchant operation | Settlement and fee reports, disputes, refunds, daily reconciliation, customer lookup, escalation, incident runbook, ownership and training |
Transaction lifecycle
Build one deterministic path through the provider ecosystem.
A custom integration should minimize ambiguous state and preserve the provider evidence needed by customers, support, fulfillment, and finance.
Discover
Confirm the merchant account, PAYARC products, CMS Max surface, payment methods, environments, data path, volume, and owners.
Design
Choose hosted or tokenized capture, define server requests, provider and CMS Max states, events, idempotency, errors, and observability.
Implement
Build protected configuration, transaction services, UI, event handlers, order mapping, refunds, logs, metrics, and support tools.
Validate
Test provider sandbox cases, browser and device journeys, security, accessibility, failures, retries, voids, refunds, and reconciliation.
Operate
Accept a live transaction and reversal, monitor production, train support and finance, review credentials, reconcile, and govern changes.
Implementation sequence
Treat the first Payarc launch as a product integration project.
The project is complete when the merchant can process, explain, reverse, support, and reconcile a transaction under real production conditions.
Document the merchant need
Define checkout or form context, payment methods, countries, currencies, amount rules, customers, fulfillment, refunds, disputes, reporting, service levels, and launch goals.
Verify the PAYARC account
Confirm approved products and environments, obtain current documentation and credentials, identify provider contacts, and resolve provider-specific requirements.
Approve the architecture
Choose the capture model, credential store, transaction and event APIs, idempotency rules, CMS Max state map, logging boundary, monitoring, and recovery.
Implement the narrow scope
Build only approved payment, capture, event, void, refund, customer, order, and reporting behavior with tests and operator-facing evidence.
Run adversarial acceptance
Exercise invalid inputs, decline, timeout, duplicate click, provider outage, delayed event, replay, partial completion, refund, permission, and reconciliation cases.
Launch with controls
Use change approval, a controlled live payment and reversal, settlement verification, dashboards, alerts, runbooks, provider escalation, training, and rollback.
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 scoped custom application work, CMS Max checkout or form experience, order and transaction mapping, monitoring integration, documentation, and agreed support boundary.
- PAYARC
- Owns merchant and partner accounts, credentials, provider products and APIs, payment processing, transaction state, settlement services, availability, and provider support.
- Merchant
- Owns provider selection and contract, underwriting, enabled products, bank accounts, fees, reserves, fraud and refund policy, disputes, and customer promises.
- Joint operation
- Owns acceptance tests, production change control, credential rotation, incident response, customer support, refund procedures, reconciliation, and scope changes.
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.
Is Payarc a native CMS Max payment gateway today?
No. The current CMS Max application does not contain a native Payarc package, settings class, payment provider, route, or feature-test surface. A connection requires a separately scoped custom implementation.
Which Payarc payment experience should a project use?
Choose from the current products enabled for the merchant, such as a hosted checkout or hosted or tokenized fields, after reviewing data flow, PCI scope, accessibility, devices, branding, API support, and operations.
How does PAYARC API authentication work?
PAYARC documents unique credentials for merchant and partner accounts and separate keys for sandbox and production. Keep tokens in protected server configuration and never expose them in public code, pages, screenshots, or logs.
Can a custom integration support voids and refunds?
PAYARC documents void and refund capabilities, but CMS Max should promise only the actions included in the merchant scope and proven with transaction-state checks, permissions, audit history, customer communication, and reconciliation.
What must be tested before launch?
Test card or ACH inputs as scoped, approval and decline, timeout, duplicate submission, provider outage, event retries and replay, cancellation, void, refund, order mapping, settlement, permissions, support lookup, and reconciliation.
Who supports the completed integration?
The scope should separate PAYARC account and processing support, CMS Max application support, merchant operations and finance ownership, incident escalation, credentials, monitoring, and changes.
How long does a Payarc integration take?
Timing depends on merchant onboarding, selected provider products, documentation and sandbox access, checkout and order requirements, security review, test breadth, operational readiness, and production acceptance. Discovery should produce the estimate.
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.