Payment workspaces, transactions and offline methods

Source version and installed-release boundary

This manual covers the reviewed newer product source workflow. It requires its matching released core, additive database structure and signed modules where applicable. The separately approved licensed 1.3.8 archive can have an earlier workflow. Do not assume these screens or commands exist merely from a numeric version label, and do not copy newer source files over a signed installation. Documentation publication does not upgrade the product or enable any external account.

Business Transactions (/admin/master/transactions) contains recorded settlements, provider-specific views and gateway review. Provider tabs use the configured payment connections, including disabled connections with historical records. Offline payments (/admin/master/transactions/offline) reviews customer bank references; acceptance retains the existing settlement, duplicate-reference and recent-password checks. The Payment source filter also offers recorded offline, account-credit and historical providers, and CSV export retains the selected source. These screens require payment permissions.

System Offline payment methods (/admin/master/offline-payment-methods) configures bank accounts, account holder names, brands, storefronts, country/currency mappings and instructions. The bank account holder is entered by the operator and may differ from the invoice seller name; availability uses the configured brand, storefront, country and currency. It requires settings.manage and does not load customer submissions or settlements. Stripe and other gateway credentials remain under System → Payment gateways.

Existing /payments links remain supported. Legacy /offline-payments?tab=methods and ?tab=review links redirect to their separate destinations; an unqualified old link respects an authorized System workspace. Method saves return to System, and reference reviews return to Business Transactions.

Regression coverage: payment-workspace-separation.php checks workspace context, canonical and legacy permissions, query/data separation, filters, frozen evidence and mutation redirects. payment-review.php checks exact provider isolation for settlements, checkout attempts and webhook review, including disabled and historical gateways. offline-payments.php retains the bank settlement and duplicate-allocation workflow checks.

Airwallex and eWAY

Install the reusable payment packages from dist/airwallex and dist/eway, then configure each connection under System → Payment gateways. Save credentials in the encrypted connection form, run Test connection, enable the connection and select it in the relevant brand/storefront gateway configuration. New connections start disabled and unverified. Do not put merchant credentials or live Cloud data in Git.

Airwallex uses PaymentIntents, a customer-authorised SDK handoff and signed webhooks with fresh server-side settlement verification. Configure the webhook URL displayed for the connection and its signing secret. Its connection currency allowlist must match currencies enabled for the merchant. eWAY uses Rapid's hosted payment page and a signed return locator followed by authenticated transaction lookups. eWAY accepts AUD invoices only and is hidden from other invoice currencies; no currency conversion or invoice repricing occurs. Credentials and sandbox/live modes are separate configuration choices. A successful connection test performs read-only queries; it does not test a real payment or webhook delivery.

Both modules reserve the checkout before contacting the provider and preserve unresolved attempts for review. Only a captured payment matching the invoice amount, currency, attempt and connection can settle the invoice. Browser returns do not establish payment success. The hosted handoff has no-store/no-referrer headers and route-specific Airwallex SDK permission; other pages retain the existing content security policy. Staff can use Business → Transactions → Gateway review for provider reconciliation. Refunds, subscriptions and automatic currency conversion are outside these initial modules.

The Airwallex customer page mounts the provider's payment selector for the reserved intent, showing the methods available to that account, invoice currency and customer environment. Card details remain inside Airwallex's component. Loading failures show a bounded diagnostic code and a same-intent retry; retrying the component creates no new checkout or payment. Wallet availability also depends on the provider's merchant, browser and domain eligibility. The hosted page permits the official static and checkout script origins for both production and demo; ordinary invoice, return and administration pages keep their existing restrictions. This includes the SDK's dynamically loaded elements bundle, not only its entry script.

The selector follows the official Drop-in integration. Run php tests/payment-hosted-return.php to export synthetic fixtures, then node tests/hosted-checkout-browser.cjs for intercepted browser checks. Optional environment variables EMAILA_HOSTED_FIXTURE_DIR, EMAILA_HOSTED_SCREENSHOT_DIR and EMAILA_CHROMIUM_PATH select fixture, evidence and browser locations. No live payment is submitted by these checks.

Regression coverage: airwallex-gateway.php, eway-gateway.php and payment-hosted-return.php use isolated databases and mocked provider calls to check currency restrictions, proof validation, checkout ownership, signed returns, pending/captured states and duplicate settlement prevention.

Airwallex card statement descriptor

Airwallex 1.0.2 adds an optional Statement descriptor under System → Payment gateways → Airwallex → Configure. Operators can edit or clear the connection’s descriptor without changing module source. A value of up to 32 characters is sent as descriptor when a new PaymentIntent is created; an empty value omits that parameter and retains Airwallex’s default registered business name. Existing attempts, captured payments and statements are unchanged.

Airwallex requires an account manager or support to enable dynamic descriptors. The local configuration field does not activate that feature, and the issuing bank controls the final statement display. Merchant-specific descriptor values belong in encrypted connection data, never in the package defaults or Git.

Connection test diagnostics

The native Test action displays a bounded configuration/provider reason in the error notice and retains it under the connection. Failed tests clear verification and keep the connection disabled; successful tests clear the old error but still require explicit enabling. Known HTTP authentication, permission, account-ID, rate-limit and connectivity errors use safe diagnostic messages. Raw provider bodies, credential values, URL query strings and stack traces are excluded. Airwallex 1.0.1 preserves these transport diagnostics. Tests in integration-test-diagnostics.php cover error display, redaction, failed operation results and verification state.

Airwallex configuration guide

Airwallex Configure shows the complete central webhook URL, a Copy URL control and an About API dialog covering matching environments, credential locations, Account Capabilities Read and Payment Acceptance Read/Write permissions, the exact payment_intent.succeeded event, webhook signing secret, shared storefront domains, supported currencies and activation. New connection forms reserve the public connection UUID in the operator session so the callback can be registered before saving credentials; validation retries retain it, the save checks it against the session, and successful creation consumes the reservation.

The configuration page retains the sanitized latest Test error and provides an independent Test form for the saved configuration. Unsaved settings must be saved before testing. Secret-field help remains visible beside the preservation hint, and required markers reflect whether an encrypted value already exists. Setup rendering and opening/copying the guide perform no provider requests or connection writes. airwallex-setup-presentation.php checks the actual rendered forms, callback identity, error redaction and reservation lifecycle.