01 / Workflow
Keep the business reference through every event
The integration is easiest to operate when the payment, player or order and settlement records share references from the beginning.
- 01
Create the session
Send the required amount, currency, business reference and return context using the current documented request shape.
- 02
Present the payment experience
Direct the customer into the configured checkout or payment route returned for that session.
- 03
Process documented events
Validate and handle the event types and fields described in the current API documentation.
- 04
Credit and reconcile
Use the payment reference to connect the event, intended player or order, credited amount and settlement record.
02 / Operations
Integration choices that affect operations
A useful integration does more than open checkout. It preserves the references, states and failure paths the operator will need after launch.
Reference design
Choose stable player, order or invoice references that can be found in both the operator system and Payfux record.
Event handling
Process only documented event fields and states, and preserve the received reference for audit and reconciliation.
Return behavior
Treat the customer return as interface navigation rather than final proof that a payment or settlement completed.
Reconciliation path
Connect payment and settlement records in the operator's own systems so differences can be investigated by reference.
03 / Requirements
The current documentation controls
Marketing examples describe the integration sequence but do not define production endpoints, payloads, signatures, retries, status values or service levels.
- Use only the authentication and request fields in the current API documentation supplied for the customer environment.
- Do not treat the browser return as authoritative payment evidence; use the documented server-side status and event model.
- Test failure, duplicate, delayed and changed-state handling against the behavior documented for the integration.
04 / Questions
Questions operators ask
Where are the current Payfux API schemas?
The current schemas, authentication requirements and request fields are in the Payfux API documentation. Product-page code examples are explanatory and do not replace it.
Should the browser return mark a payment as complete?
No. The customer return is navigation. The operator should use the documented server-side payment status and event evidence for crediting and reconciliation.
Does Payfux promise a particular event retry schedule?
No retry schedule is claimed on this page. Implement the event and recovery behavior stated in the current customer documentation.
Which business reference should an operator send?
Use the stable player, customer, invoice or order reference required by the documented integration and preserve it in the operator system.
Are test and live records interchangeable?
No. Keep environment credentials, endpoints, records and reconciliation separate and follow the environment controls stated in the documentation.
Developer documentation
Start with the current request and event schemas
Use the Payfux documentation for exact integration behavior, then align the payment references with your operator systems.
Read the docs