eWAY Rapid Hosted Payments — setup and reference

Module and release scope

This guide covers eWAY Rapid Hosted Payments 1.0.0, Extension API 1, from the reviewed product source. Its declared core range is 1.3.5–1.3.99. Use the matching released core and signed provider package; a version label alone does not install the required contracts. Source availability does not mean the module is bundled in every currently downloadable product, installed on your server, enabled or certified for your merchant/server account. Nothing in this guide enables a provider or changes your existing connections.

Open System → Payment gateways (newer source may group these as Payments, Domain services or Hosting services). Install the reviewed signed package through Modules & addons or the integration workspace's Install tab, enable the module separately, add an account/connection, save its own credentials, run its stated Test and explicitly enable the connection. Saving or retesting disables the connection until you enable it again. Start with the provider's test environment where supported; otherwise use an isolated account or server.

Exact connection fields

These are the fields declared by this module. Secret values are entered privately and encrypted by the application. Defaults are configuration hints, not approved live merchant settings. Internal fields are populated by the module and are not operator-editable.

Key / label	Type	Required	Default / guidance
mode — Environment	select	Yes	Default: "sandbox" Choices: sandbox = Sandbox, live = Live
api_key — Rapid API key	secret	Yes	Use the Rapid API key, not your MyEway login or public encryption key.
api_password — Rapid API password	secret	Yes	Use the account-specific value described below.

This payment module sends customers to eWAY's Responsive Shared Page. eWAY collects their card details; EmailaBiller does not collect a card number, CVV or reusable card token.

Configure

Install the signed module, then add an eWAY payment-gateway connection in System → Payment gateways. Select Sandbox or Live, enter the account's Rapid API key and Rapid API password, and run Test connection. These are separate from a MyEway login or public encryption key. The connection test makes a read-only transaction query and does not submit a card authorisation or payment. Enable and assign the verified gateway to the intended brand/storefront using the existing gateway controls.

The module accepts AUD invoices only. Other invoice currencies do not show eWAY as an available payment method and are rejected if submitted directly. The module never changes an invoice currency, calculates an exchange rate or converts amounts. Customers with non-AUD invoices can choose another configured gateway or an applicable offline payment method.

Sandbox and live credentials must match the selected environment. API destinations are fixed to eWAY's official hosts. Hosted page appearance is taken from the merchant's MyEway Shared Page settings.

Payment confirmation

Checkout creation uses Rapid v47 AccessCodesShared with ProcessPayment, Purchase, exact invoice cents and the application's unique checkout attempt reference. The module preserves the application's signed return URL and checks the returned hosted URL, AccessCode, amount, currency and attempt reference before redirecting.

The browser's return is a locator, not proof of payment. Confirmation makes authenticated reads of AccessCode/{AccessCode} and Transaction/{AccessCode}. Their transaction ID, attempt reference and amount must agree. The query must confirm a successful captured purchase, AUD's numeric currency code and a supported full-approval response without an unresolved fraud-review action. The application then independently checks the stored checkout identity, invoice amount/currency and signed return before recording the payment. Stable transaction IDs prevent duplicate ledger entries.

Unsigned webhook claims do not record payments. Partial approvals, uncaptured authorisations, refunds, unresolved fraud reviews, mismatches and uncertain API results stay under billing review. An abandoned checkout is never assumed to have expired merely because the customer closed the browser. Staff can use the existing checkout reconciliation action to repeat the same authenticated provider checks.

Checkout creation is never retried automatically after a timeout. Check the gateway before attempting another payment. AccessCode results are available from eWAY for one week; older unresolved attempts require provider-led reconciliation rather than an invented unpaid status.

Verification

Run php tests/eway-gateway.php. The isolated test harness mocks all provider requests and never uses the installation database or a real merchant account. A merchant sandbox checkout remains necessary before enabling a production connection.

Official implementation reference: eWAY Rapid API, including Responsive Shared Page, AccessCode results, Transaction Query and response codes. Reviewed 20 October 2026.