Payments Guide
This guide covers everything you need to know about creating and managing payments through the LuxCore API.Payment Types
LuxCore supports four payment types:Payment Methods
Supported Payment Currencies
Creating a Deposit (Customer Payment)
When a customer needs to pay you:- ARS (Argentina)
- MXN (Mexico)
- UYU (Uruguay)
- AUD (Australia)
- TRY (Turkey)
- LKR (Sri Lanka)
Creating a Withdrawal (Payout)
To send money to a beneficiary:customer vs payout: For withdrawals, both objects refer to the same person — the recipient of the funds.customer— personal contact information (name, email, phone). Used for customer identification, matching, and communication.payout— bank account details for executing the transfer (account number, bank code, reference).
Payout Fields
- ARS (Argentina)
- MXN (Mexico)
- UYU (Uruguay)
- AUD (Australia)
Per-Payment Webhook URL
You can optionally specify awebhook_url to receive events for a specific payment without pre-configuring a webhook endpoint:
In-request webhooks are signed using your merchant’s default webhook secret. See the Webhooks Guide for details on signature verification and secret management.
Traffic Type
Optionally tag payments with a traffic type for analytics and routing:traffic_type is optional. If not provided, the payment uses default routing. Traffic type is included in payment responses and CSV exports.Hosted Payment Pages
For a simpler integration, use hosted payment pages (deposit_pp or withdrawal_pp):
The payment page URL is dynamically generated and may vary based on the selected currency, payment method, and region. Always use the exact URL returned in the API response.
Payment Statuses
Understanding payment statuses is crucial for proper integration. Each status represents a specific state in the payment lifecycle.Status Reference
Terminal statuses (
completed, failed, cancelled, expired, refunded, partial_refund) are final states - the payment cannot transition to non-terminal status.Initial Status by Payment Type
Status Descriptions
created
created
The payment has been created in the system but has not yet been assigned to a payment provider or requisite. This is a transient status that typically transitions quickly to
pending or processing.Next possible statuses: pending, processing, failedpending_approval
pending_approval
The payment requires manual approval before it can be processed. This may apply to high-value transactions or flagged payments that need review.Next possible statuses:
processing, cancelledpending
pending
The payment has been created and is waiting to be processed. For withdrawals, this means the payout is queued and awaiting approval or processing by the payment provider.Next possible statuses:
processing, cancelled, expiredprocessing
processing
The payment is actively being processed. For deposits, this means the customer has been given payment instructions (bank details, payment page URL) and we are waiting for them to complete the transfer.Next possible statuses:
completed, failed, cancelled, expiredcompleted
completed
The payment was successful. For deposits, the funds have been received and credited to your merchant balance. For withdrawals, the funds have been sent to the beneficiary.This is a terminal status. You will receive a
payment.completed webhook.failed
failed
The payment could not be completed. This can happen due to various reasons: bank rejection, invalid account details, insufficient funds (for withdrawals), or technical issues.This is a terminal status. You will receive a
payment.failed webhook with an error_code and error_message.cancelled
cancelled
The payment was cancelled before completion. This can be initiated by the merchant via API, by an admin, or automatically by the system.This is a terminal status. You will receive a
payment.cancelled webhook.expired
expired
The payment was not completed within the allowed time window. Deposits typically expire after 1-60 minutes (configurable per merchant).This is a terminal status. You will receive a
payment.failed webhook with error_code: TTL_EXPIRED.refunded
refunded
The payment was fully refunded after completion. The refunded amount has been deducted from your merchant balance.This is a terminal status. You will receive a
payment.refunded webhook.partial_refund
partial_refund
The payment was partially refunded. Part of the original amount has been returned to the customer.This is a terminal status. You will receive a
payment.refunded webhook with the refunded amount.Initiating Refunds
Refunds are currently initiated through the support team. A programmatic Refunds API is planned for Q2 2026.
- Create a support ticket with category
refund_requestvia the Tickets API or the merchant dashboard - Include the
payment_idof the payment to be refunded - The support team will process the refund and update the payment status
- You will receive a
payment.refundedwebhook when the refund is complete
available_amount decreases).
Handling Status Changes
Retrieving Payment Status
Listing Payments
Query Parameters
Customer Management
Payments are automatically linked to customers in your account. You can optionally pass an existing customer ID to link a payment to a specific customer.Customer Fields
All
customer fields are optional. However, providing at least email or phone is recommended for automatic customer matching and communication.external_id is your own customer reference (e.g., user ID from your database). It is stored on the customer record and is unique per merchant. Use it for reconciliation and analytics without relying on LuxCore internal IDs.Automatic Customer Matching
When creating a payment, if you don’t provide acustomer_id, the system will:
- Search for an existing customer by email (exact match, case-insensitive)
- If not found by email, search by phone (normalized)
- If no match found, create a new customer with the provided data
external_id is provided and a customer is found by email or phone, the external_id will be assigned to the existing customer (if not already set).
Using External ID
Passexternal_id inside the customer object to link payments to your internal customer records:
Using Customer ID
If you have an existing customer, you can pass their ID directly:When
customer_id is provided, the system validates that the customer exists and belongs to your merchant account. The customer object fields (name, email, phone, external_id) are not updated in this case — only the link to the existing customer is used.Customer in Response
Payment responses now include customer information:Cancelling a Payment
Cancel a pending payment:Only payments in
pending status can be cancelled.Idempotency
Use uniquemerchant_reference values for idempotency. If you submit a payment with a reference that was already used, the API will return the existing payment instead of creating a duplicate.
Best Practices
Validate Amounts
Always validate amounts before submission. Amounts are in minor units (centavos).
Handle Webhooks
Don’t rely on polling. Set up webhooks for real-time status updates.
Store References
Save
transaction_id and merchant_reference for reconciliation.Check Balance
For withdrawals, verify sufficient balance before initiating.
