Platforms supporting Australian payment solutions
Introduction
The Australian market makes its payment requirements: players expect instant bank transfers (POLi, PayID/Osko), local billing methods (BPAY), vouchers (Neosurf) and BNPL services (Afterpay). Proper integration increases conversion, reduces failures and ensures compliance with regulations.
1. Main methods and their features
1. POLi Payments
Instant bank transfer without cards: OAuth-authorization of the user in the bank, redirect back with 'transactionRef'.
API:
Classic billing through Biller Code and Customer Reference.
Process:
Fast Settlement: transfer to (email/phone) via New Payments Platform.
API integration via PSP: 'POST/payments/osko/pay {payId, amount}' with quick response and Webhook on enrollment.
4. Neosurf
Prepaid vouchers purchased at point-of-sale.
UI: enter 10-digit code; Provider API returns'approved 'or' declined '.
5. Afterpay (BNPL)
Allows you to split the payment into four parts.
Integration via Checkout API:
2. Integration architecture
```mermaid
flowchart LR
API-Gateway: single entry point, request validation, rate-limiting.
PaymentService: abstraction of all methods, stores' paymentId ',' method ',' status', 'metadata'.
TransactionService: atomic record of financial transactions, ACID guarantee.
AuditDB: immutable request logs and webhooks.
3. Handling webhooks and callbacks
1. Identification:
The Australian market makes its payment requirements: players expect instant bank transfers (POLi, PayID/Osko), local billing methods (BPAY), vouchers (Neosurf) and BNPL services (Afterpay). Proper integration increases conversion, reduces failures and ensures compliance with regulations.
1. Main methods and their features
1. POLi Payments
Instant bank transfer without cards: OAuth-authorization of the user in the bank, redirect back with 'transactionRef'.
API:
- `POST /payments/poli/init {amount, currency: "AUD", returnUrl}` → `paymentId, poliUrl`.
- Webhook `/payments/poli/callback {paymentId, status, bankRef}`.
- 2. BPAY
Classic billing through Biller Code and Customer Reference.
Process:
- `POST /payments/bpay/generate {amount}` → `billerCode, customerRef, expiryDate`.
- Upon receipt of funds, the bank sends a callback or the polling API of the provider is required.
- 3. PayID / Osko (NPP)
Fast Settlement: transfer to (email/phone) via New Payments Platform.
API integration via PSP: 'POST/payments/osko/pay {payId, amount}' with quick response and Webhook on enrollment.
4. Neosurf
Prepaid vouchers purchased at point-of-sale.
UI: enter 10-digit code; Provider API returns'approved 'or' declined '.
5. Afterpay (BNPL)
Allows you to split the payment into four parts.
Integration via Checkout API:
- `POST /afterpay/orders {amount, currency, returnUrl}` → `orderId, redirectUrl`.
- Webhook `/payments/afterpay/notification {orderId, status}`.
2. Integration architecture
```mermaid
flowchart LR
| Player --> | initiate payment | API-Gateway |
|---|---|---|
| API-Gateway --> PaymentService | ||
| PaymentService --> | init POLi/BPAY/Osko/... | PSP-API |
| PSP-API --> | redirect or token | Player |
| PSP-API --> | webhook | PaymentService |
| PaymentService --> TransactionService | ||
| TransactionService --> AuditDB | ||
| ``` |
API-Gateway: single entry point, request validation, rate-limiting.
PaymentService: abstraction of all methods, stores' paymentId ',' method ',' status', 'metadata'.
TransactionService: atomic record of financial transactions, ACID guarantee.
AuditDB: immutable request logs and webhooks.
3. Handling webhooks and callbacks
1. Identification:
- HMAC signature in the header ('X-Signature'), checking for a common secret. 2. Idempotency:
- Using 'paymentId' and 'idempotencyKey' to protect against duplicates. 3. Statuses:
- `pending` → `approved`/`declined`/`failed`.
- When 'approved', 'fundsCredited' workflow is launched: updating the balance, issuing bonuses.
4. Localization and currency control
AUD currency: all amounts in 'currency: "AUD"', format in UI - 'Intl. NumberFormat('en-AU', { style: 'currency', currency: 'AUD' })`.
Local content: texts, conditions and warnings in English with an AU version (color/color, tire/tire).
TimeZone: UTC + 10/11, calculation of cut-off for BPAY payments in Australian time.
5. Safety and compliance
PCI DSS Scope minimization: when using PSP-redirect and Invoice API, card data does not pass through your platform.
KYC/AML: mandatory verification before first output, PEP/Sanctions check.
Responsible Gambling: reminders about limits, self-exclusion by geolocation API (geo-zone AU).
6. Fault tolerance and scaling
Retry Logic: Exponential backoff for POLi and Osko on transient errors.
Circuit Breaker: Hystrix/Resilience4j for PSP calls, disabling the method when error-rate is high.
Auto-scaling: Kubernetes HPA for PaymentService by QPS and webhook latency.
7. Integration testing
Sandbox PSP mode: test endpoints, dummy tokens ('test _ poli _ 123').
E2E tests: Cypress/Playwright scripts: initiate payment → emulate webhook → check balance.
Load Testing: k6 scripts with parallel calls '/payments/init 'and '/payments/callback'.
Conclusion
The integration of Australian payment solutions on the online casino platform requires a single abstraction of methods, reliable webhook processing, secure architecture and localization for AUD and AU regulation. The comprehensive approach provides a high conversion rate, fast processing of receipts and compliance with security standards.
