Connect Acumatica to DreamPay

Current installation and operating limits

Updated 19 October 2026. The operator confirmed publication of Cloud 1.1.0 (level 110), corrected Workflow 1.1.2 (level 115), Reader 1.0.8 (level 120) and Sales Orders 0.1.0 (level 125). Existing project names contain older versions; verify their contents. Do not restart installation or import duplicate projects. The separate backend branch-reader correction is 0.1.2.

The configured connection is still the exact tenant CHT Sandbox, endpoint DreamPaySandbox / 25.200.001, branch CHT, CAD, DPSBX/TESTCASH, using Nuvei Test mode. This is not a production profile. A production tenant requires its own authorized OAuth grant, Reader/environment profile, accounting mapping and live merchant/site credentials. The current ERP and provider implementation is test-only; changing an enablement flag cannot make it production capable.

Invoice 000042/payment 000034 and posted GL batch 000076 are retained historical invoice-payment evidence. The complete quotation/order/advance/shipment/invoice/remainder flow has not been financially verified. No new charge or accounting document was created for this update.

Normal business-user access

Use the existing DreamPay Payments role for collection actions and DreamPay Viewer for read-only status, together with effective screen/action rights and existing tenant, branch and customer access. There is no backend username allowlist restricting this to the tester. Administrator alone does not satisfy the DreamPay role guard. Do not give business users the internal Authorization Reader role. Keep Refund and Void privileges separate.

Sales-order availability

Generate Advance is eligible only for a saved, authorized Open or Awaiting Payment SO order with a valid current connection and prerequisites. A Pending Approval order is ineligible; follow its assigned approval process rather than changing the approval map. Modern UI tab rendering is reported, but Classic UI rendering and current business-user rights remain unverified. A prepared native status/access correction adds a local availability explanation and status actions in nonpayable states; it is not yet published.

The native order extension still shares the AR101000 Workflow switch. Its current saved state must be established before any change; the server flag does not prove the checkbox state. New order advances remain disabled. Order-advance refunds/voids, split or combined invoices, FX and unsupported adjustment histories remain unsupported or review-required. Uncertain outcomes must be reconciled by their existing references without another charge.

Compatibility and exact setup values

The current packages require the exact Acumatica tenant name CHT Sandbox and endpoint DreamPaySandbox. These are technical identifiers, not product names. The installed AR101000 tab is labeled DreamPay Sandbox. Preserve these values during setup; other environments require separate provisioning.

1. Minimum configuration checklist

• Confirm the exact installed build and application hosting scope, an authorized test tenant, API/session licensing and necessary AR/GL features. Selecting a tenant alone does not isolate shared website code.
• Export the current customization set, endpoint mappings and permissions; obtain a recoverable application/database backup. Preserve unrelated projects and records.
• Install the compatible Cloud 1.1.0, corrected Workflow 1.1.2 and Reader 1.0.8 set. Leave Workflow OFF until readiness checks pass.
• Use a separate tenant-bound OAuth application and authorized grant, private credentials, durable writable token storage and the exact registered callback.
• Validate DreamPaySandbox /25.200.001, nine Reader fields, keyed read, explicit write denial and service-role boundary.
• Verify cash account Active/currency, branch, payment-method Use in AR, non-integrated external bookkeeping and open AR/GL posting periods.
• Obtain genuine cash-screen evidence less than 24 hours old; inspect its expiry in the integration status.
• Verify matching public connection reference, authenticated webhooks and idempotent reconciliation. Confirm restricted tester rights before enabling native Workflow.

2. Separate administrator, service and tester access

Use Users SM201010, Access Rights by Role SM201025 and Access Rights by User SM201055 to inspect assignments and computed effective rights. Record each intended active human user's authorized tenant, branch and customer restrictions. Verify fresh login with a restricted tester; administrator success does not establish tester access.

Preserve intentional no-Reader accounts and negative tests. Human testers must not acquire Reader/service privileges merely to make status work. Effective rights, tenant menu, branch/customer visibility and fresh login all require verification; a role checkbox alone is insufficient.

3. Backup, import, validate, publish and upgrade

1. Verify About Acumatica shows 26.100.0175. If different, stop: the downloadable binaries are unsupported for that build.
2. Export current projects, record all selected projects/levels and preserve TEST. Establish whether the application instance is shared with production. Compiled code and website files can affect every tenant in the instance; do not publish changes affecting production under test-only authorization.
3. Download the compatible installation set. Extract the complete installation set. Import the individual customization ZIPs below, not the outer installation bundle. Check SHA256SUMS.txt with shasum -a 256 FILE.zip or PowerShell Get-FileHash FILE.zip -Algorithm SHA256.
4. In Customization Projects SM204505, import base Cloud1.1.0 only if missing. Replace content in the existing Workflow/Reader projects using the supported import/replace route. Do not create duplicate projects owning the same DLL. Use levels110/115/120 respectively, then validate and publish the complete selected set in authorized scope.
5. The Workflow ZIP must be 1.1.2-CloudImportFix. It corrects the Modern UI import to src/screens/AR/AR301000/AR301000; its DLL is1.1.2.0. The original unmodified1.1.2 ZIP failed cloud publication. Project names ending AmountDialog1.1.1 do not establish content version.
6. Keep Reader1.0.8 and the DP201000 data-source visibility fix. Never use superseded EncryptedStorage or migrate instance certificates for this cloud solution.
7. In SM207060, preserve the existing DreamPaySandbox/25.200.001 endpoint extending Default/25.200.001. DreamPayUIRequest maps to DP201000: ProofKey (key), RequestID, TenantLogin, ConnectionReference, ActorID, ActorName, CreatedAtUtc, ExpiresAtUtc, Payload. Validate all nine. UTC storage fields may serialize without a timezone suffix; interpret those two explicitly as UTC.

Rollback: turn Workflow OFF, save and reopen; restore prior exported project content and the previous complete approved project set. Preserve accounting records, endpoint mappings and Reader1.0.8. Do not delete tables or unpublish unrelated projects. For website rollback, use the saved deployment start script/release. Never roll OAuth tokens back to an old refresh token. Reconcile existing captures separately.

4. Connect the authorized environment securely

1. In Connected Applications SM303010 create an application for the specific test environment using Authorization Code. Configure its shared secret privately and a redirect URI matching the listener that will actually receive the callback. Never publish the secret, token or full Client ID in shared training evidence.
2. The existing CHT setup uses http://127.0.0.1:8787/acumatica/callback, with a loopback listener reached through the prepared private setup/tunnel. This is the registered callback for that existing flow, not a universal hosted callback. A different environment must have its own approved callback and application configuration; a public hosted callback is not supplied by this installer.
3. Use state validation and PKCE S256. Request exactly api offline_access. The client ID includes the authorized tenant suffix; verify the actual API identity and tenant independently. Do not infer identity from the Connected Application name.
4. Use discovery at /identity/.well-known/openid-configuration; authorization/code exchange are /identity/connect/authorize and /identity/connect/token. Sign in as the approved integration identity through the fresh authorization flow.
5. Store credentials server-side using private references. CHT's credentials/configuration remain read-only to the service; rotating tokens are stored in a dedicated private state directory (0700, token files0600) allowed by systemd's narrow ReadWritePaths while ProtectSystem=strict stays enabled. Never require tenant administrators to back up machine keys, move certificates or store plaintext keys in Acumatica.
6. Rotate access and replacement refresh tokens atomically. Serialize refresh with a lock; do not delete a lock without ownership/age evidence. Verify renewal in the actual service execution context and after restart. Refresh-token expiry/revocation requires a new interactive authorization, not repeated refresh attempts.
7. Run a read-only connection/Reader test and confirm only the approved tenant/merchant binding. A different merchant's setup request remains inactive pending its own guarded build, private grant and compatibility acceptance. It cannot borrow CHT's connection.

Official authorization-code, exact callback and PKCE reference.

5. Cash account, payment method and periods

Open Cash Accounts CA202000 in the correct test. CHT's example is TESTCASH, Active, CAD; DPSBX with Use in AR; branch CHT. These are CHT-specific values, not defaults for another environment. Confirm the payment method is active, available to AR and does not invoke Acumatica integrated card processing: DreamPay records externally verified captures. Verify branch independently through the supported mapping endpoint.

Confirm AR and GL posting periods are open for the transaction/application date and the integration identity has the required branch/customer and payment/release rights. The workflow records a payment and application; it never edits an invoice's paid status directly.

When cash currency/Active are not exposed by the endpoint, genuinely open CA202000 and record tenant, screen, cash account, Active, currency, payment-method Use in AR and observation timestamp. A server operator stores that attestation privately. Evidence expires after 24 hours; live method/branch checks still run. The website shows observation/expiry and blocks readiness when invalid. Never re-date yesterday's evidence or extend the limit.

6. Activate only after readiness passes

1. Open Integrations → Acumatica Integration in DreamPay. Confirm it shows the current workspace's test binding, readable Reader proof and valid mapping/evidence. Server readiness does not prove native Workflow or human-user rights.
2. In Accounts Receivable Preferences AR101000 → DreamPay Sandbox, enter the separately provisioned public connection reference. A reference is not a secret or OAuth token and must match the server's tenant/merchant binding.
3. Enable Workflow, Save, navigate away and reopen AR101000. Verify it remains checked. Sign in freshly as the restricted tester and inspect the eligible invoice screen. If Save did not persist, activation is not complete.
4. Keep production inactive. Do not bypass disabled controls or fix missing actions by granting Administrator/Reader to testers.

7. Everyday testing in Test mode checklist

1. Use a new labelled disposable saved, released, Open CAD invoice with positive balance in your permitted branch/customer scope. Unreleased, held, closed, zero-balance, wrong-currency or unauthorized invoices are ineligible.
2. In Invoices and Memos AR301000, open DreamPay. Refresh status and check prerequisites before generating a link. A status failure must leave normal invoice loading usable while payment actions remain blocked.
3. Choose Generate Payment Link or Pay with DreamPay. Enter a positive amount up to the unreserved outstanding balance, in cents (at most two decimal places). The payment-dialog Amount field may be editable while the invoice remains View Only.
4. Confirm once. Reopen/reuse the existing reserved link after a duplicate click or uncertain response; do not generate another link to escape uncertainty. A second partial installment is allowed only within the current balance after prior reconciliation.
5. Open the secure checkout. Confirm the test environment label and amount, use only Nuvei-published test cards, and submit once. Never use real card data. No card data belongs in support logs or screenshots.
6. Refresh status after completion. Approved checkout alone does not prove accounting completion. Expect DreamPay paid, verified capture and authenticated webhook, sync synced with no error, one released Acumatica payment/application, expected remaining invoice balance and a posted balanced AR GL batch.
7. For partial payments the invoice remains Open with the exact remainder; after the final payment it becomes Closed with zero balance. A declined/cancelled/pending/Auth3D-only attempt must create no capture-authorized ERP payment.
8. Use Retry Declined only after a definitive provider decline and its retained verification, never after timeout or pending. Cancellation or expiry is not evidence that no charge occurred: inspect the existing transaction first.
9. If a response is uncertain, stop submitting. Have the operator reconcile by the original invoice/link/provider/ERP unique reference. Never charge again to resolve a sync failure.

8. Troubleshooting and reconciliation

Webhook authentication precedes capture processing. Duplicate event/order/transaction checks and ERP unique references are separate safeguards. An authenticated-inbox replay reuses already trusted facts; it is not a signed HTTP replay. A signed-wire replay remains a distinct test until exercised.

9. Refunds, voids and acceptance boundaries

Refund and Void are separate permissions and disabled in the current native binding unless specifically enabled for supported tests. Existing reversal accounting supports narrowly defined fully reconciled CAD1.00, zero-tax test fixtures and its approved mappings. Arbitrary refunds, partial refunds and arbitrary invoice layouts are unsupported. A provider-rejected Void is a failed/unsupported Void result; a later refund must never be called a passed Void.

Separate published functionality from financially verified behavior and preserve completed acceptance documents. Do not create demonstration transactions to establish a readiness claim. Label local simulations separately from actual provider/ERP execution. Include concurrency, stale evidence, role/tenant/branch/customer boundaries and Classic/Modern UI. A website release or test Sale does not establish wallet, MIT,3DS or certification completion.

Course completion criteria

An administrator can reproduce the exact supported configuration without exposing secrets. A restricted tester can navigate the native workflow within authorized scope, submit one bounded test payment, and verify all provider, webhook, ERP application, invoice and GL results. Missing native access, unsupported builds and untested cases remain visible blockers.

Installation downloadsConnection status