Apcopay and Trust Payments: Planning a Reliable Store Integration

A reliable payment integration connects a server-created order to the provider's verified payment result. Showing a payment page is only one step; the shop must also handle delayed notifications, cancellations, duplicates and refunds correctly.

Choose the supported integration route

Start with the provider and merchant account you will actually use. Ask about a maintained platform plugin, hosted payment page or another supported method. Apcopay documents a hosted-page flow with payment notifications, while Trust Payments documents URL notifications following payments. Follow the documentation for the selected product rather than mixing examples from different APIs.

Confirm who handles merchant onboarding and which payment methods your account may process. Record the plugin/API version, support contact and responsibility for updates. A demonstration working with a developer's account is not evidence that your production merchant account is ready.

Keep the order authoritative on the server

Create the order reference, amount, currency and item summary on the server. Do not trust values supplied by the customer's browser. Save the intended transaction before redirecting to payment, and connect the provider's transaction reference to that record. Keep credentials in private configuration.

Use explicit order states such as awaiting payment, paid, failed, cancelled and refunded. Decide which states permit dispatch or booking confirmation. A customer returning to a success URL should see a useful status, but the URL alone must not release goods or mark an unpaid order as settled.

Verify and safely repeat notifications

Authenticate notifications using the provider's current method and verify that the amount, currency and order match the expected transaction. Make processing idempotent: receiving the same legitimate event twice must not dispatch two parcels or send duplicate fulfilment instructions. Record enough transaction information for investigation without storing card details.

Plan for delay and reordering. A notification may arrive after the browser returns, and a retry can arrive after staff have already reviewed the order. Define how conflicting states are reconciled against the provider's server-side transaction record. Avoid assumptions that events always arrive once or in a convenient sequence.

Test operational failures, not only approval

Use a sandbox to test rejection, abandonment, authentication challenges and interrupted connections. Simulate a duplicate notification and confirm that only one fulfilment action occurs. Check what happens if notification delivery is temporarily unavailable and how the order is reconciled later.

Test refunds with authorised staff and distinguish full from partial refunds. Confirm how stock, customer messages and accounting records respond. Keep a practical incident procedure so staff know whether to investigate the merchant dashboard, the shop order or an integration error before asking the customer to pay again.

Launch with clear ownership

• Keep production and test credentials separate.
• Use HTTPS and provider-prescribed notification validation.
• Have the business own its merchant account and recovery contacts.
• Record a deployment and rollback plan that preserves order history.
• Assign responsibility for reconciliation and software updates.

A hosted solution can reduce direct card-data handling, but it does not remove all merchant security or compliance responsibilities. Confirm those with the provider. Our payment-provider comparison helps with selection; this checklist helps ensure the chosen integration supports the whole order lifecycle.

Sources and review

Official references checked on 18 October 2026. Provider terms, funding calls and technical documentation can change; verify the applicable version before committing to a purchase or application.

• Apcopay hosted payment page flow
• Trust Payments URL notifications