Payments Guide
This guide covers everything you need to know about creating and managing payments through the LuxCore API.Response Metadata
Merchant custom fields supplied in the creation request’smetadata are returned in payment responses. They do not grant device access or override processing policy. Server fields such as expiry, payment type and the public commission total take precedence when names overlap.
Payment responses expose the documented merchant fields. Use your own references to link payments to orders.
Payment Types
LuxCore supports four payment types:Payment Methods
Availability and processing times depend on the route enabled for your merchant. The times below are indicative, not completion guarantees. Use the returned payment instructions and expiry.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)
Fastoo Cross-Border Routes
For Fastoo wallet, bank and SEPA payouts, usemethod: "bank_transfer" with payout.fastooDestination. Use a currency enabled for your merchant and route; these requests do not perform automatic currency conversion.
See Fastoo Cross-Border Payments for destination formats, request examples and payment status handling. The legacy bank-account payout fields below do not apply to typed Fastoo destinations.
Creating a Withdrawal (Payout)
To send money to a beneficiary:customer vs payout: For withdrawals, both objects refer to the recipient of the funds.customer— personal contact information (name, email, phone) for identification and communicationpayout— destination details for the transfer (account number, bank code, reference)
Payout Fields
These fields describe legacy bank payouts. For a typed Fastoo payout,fastooDestination replaces the legacy destination fields and recipient_name is optional; see the Fastoo contract.
- 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
These are typical nonterminal initial statuses. A creation request can also return a failed payment; always inspect the actual response.Status Descriptions
created
created
The payment has been accepted and is awaiting processing. Check its status or wait for the next notification.Next possible statuses:
pending, processing, failedpending
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. Check the final payment status before starting another payment.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. Use the Tickets
API to request a refund.
- 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).
Only completed deposits can be refunded; payouts and payments that are still pending or processing are not eligible.
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 customer identification and communication.external_id is your own customer reference (e.g., user ID from your
database). Use it to associate payments with your customer records.Using External ID
Passexternal_id inside the customer object to link payments to your 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 References
Store your own order/customer references together with the returned payment identifier. The create response usestransaction_id; payment lookups use id. Do not require a full customer object in a payment response.
Cancelling a Payment
Cancel a pending payment:Cancellation can be requested for
pending or processing payments. Payouts
(withdrawals) can be cancelled only while they are pending and not yet
assigned for processing. Cancellation may be rejected when the payment can no
longer be safely cancelled; verify the returned status before creating a
replacement. An already cancelled payment retains that status.Idempotency
Use a uniquemerchant_reference for each order. An existing active reference can return the original payment. References from failed, expired or cancelled payments may be reused; after a timeout or unknown result, check the original outcome before submitting another creation request. Do not assume that reusing a reference makes every retry safe.
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.
