API Pix (1.0)

Swagger

Environments

Staging Environment: https://seamless.stg.lbpay.com.br/

Production Environment: Provided once you complete the testing

---

This document provides the technical specifications for integrating with our PIX API, designed for iGaming platforms. Follow the guidelines below to ensure a successful implementation.

Terminology

• PIX Processor: London Bridge, acting as the Banking-as-a-Service (BaaS) provider responsible for processing PIX transactions.
• Gaming Operator: The iGaming platform integrating with this API.
• Deposit (Pix-In): When a player initiates a deposit request, an invoice is generated as a PIX QR Code or copy-and-paste payload. The player pays this invoice to credit their gaming wallet.
• Withdrawal (Pix-Out): When a player requests a withdrawal, a PIX transfer (cash-out) is executed to the player’s bank account.
• Refund: Returning the funds of a previously completed deposit back to the player.
• Internal Transfer: Instantaneous transfers between gaming wallets.

---

API Controllers

Note: All API requests must be prefixed with /v1 in the URL path.

Controller	Description
Pix-In	Core endpoints for creating and retrieving player deposit transactions.
Pix-Out	Core endpoints for initiating and querying player withdrawal transactions.
Pix Refund	Endpoints used to return funds from previously completed deposits.
Internal Transfer	Endpoints that manage wallet‑to‑wallet transfers within the operator’s environment.
Webhook	Endpoints used to configure callback URLs and receive asynchronous notifications from the platform.
Balance	Endpoints for querying account balances, including real-time and closing-day balances.

---

Authentication & Security

Authorization Using a Dedicated API Key

To access the API, you must use a dedicated API Key assigned to your environment. Please contact our support team to request your credentials. Include your authentication token in the request header of every request, following the format and guidelines provided by your integration manager.

---

Webhook Notifications

Operators must implement a webhook endpoint capable of receiving real-time notifications from our platform. Whenever a transaction changes status (e.g., a deposit is confirmed), a webhook event is sent to the URL configured by the operator.

Webhook configuration and management can be handled through the Webhook endpoints available in this API.

Our notification system includes automatic retry logic. However, to ensure full reconciliation of events, we strongly recommend maintaining a fallback polling mechanism to retrieve any undelivered status updates in the event your service becomes temporarily unavailable.

---

Customer Journey for Deposits

1. The player logs into the gaming operator’s platform and selects Pix as the deposit method. 2. The player chooses a predefined amount or enters a custom deposit value. 3. The operator generates a Pix charge (QR Code and Copy-and-Paste payload) using the POST /v1/pix/deposit endpoint. 4. The player scans the QR Code or pastes the payload into their banking app to complete the payment. 5. Our platform processes the transaction and sends a real-time webhook notification to the operator with the final status. 6. Upon receiving the notification, the operator immediately credits the player’s gaming wallet.

---

Customer Journey for Withdrawals

1. The player submits a withdrawal request from their gaming wallet. 2. The player provides the Pix key associated with their bank account (CPF, email, phone number, or random key). 3. After validating the player’s balance and compliance rules, the operator sends a withdrawal request through the POST /v1/pix/withdraw endpoint, including the Pix key and the requested amount. 4. Our API processes the Pix cash-out and transfers the funds to the player’s bank account within seconds. 5. A real-time webhook notification is sent to the operator confirming the successful settlement of the withdrawal.

---

Timeouts and Expirations

Pix-In charges (deposit requests) include a mandatory expiration period set through the expiration parameter (either platform default or operator-defined). If a player attempts to pay a Pix charge after its expiration time has elapsed, the issuing bank will reject the payment immediately at the banking-app level. No funds will be transferred to the processor or to the operator.

---

Test Data (Staging Environment)

During integration in the Staging Environment, you may use the mock CPF values listed below to simulate various validation and compliance scenarios. These tests do not involve real funds and are intended solely for development purposes:

Test CPF	Simulated Scenario
123.456.789-09	Simulates a fully successful and valid transaction.
051.375.187-43	Simulates a failure due to “Deceased” CPF status.
211.115.937-95	Simulates a failure due to “Minor” (underage) status.
222.333.444-55	Simulates a generic mismatch or rejection scenario.

These test values allow you to verify business logic, error handling, and webhook reception without any financial impact.