Skip to main content

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’s metadata 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

All amounts are in minor units (centavos, cents). For example, to charge 1,000.00 ARS, pass amount: 100000. Passing 1000 would create a payment for only 10.00 ARS.

Creating a Deposit (Customer Payment)

When a customer needs to pay you:

Response (ARS)

Fastoo Cross-Border Routes

For Fastoo wallet, bank and SEPA payouts, use method: "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 communication
  • payout — 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.

Response (ARS Withdrawal)

Withdrawals require sufficient balance in your merchant account. Use the Balance API to check available funds before initiating payouts.

Per-Payment Webhook URL

You can optionally specify a webhook_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):
Response includes a payment page URL:
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.
Redirect your customer to this URL to complete the payment.

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

The payment has been accepted and is awaiting processing. Check its status or wait for the next notification.Next possible statuses: pending, processing, failed
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, expired
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, expired
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.
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.
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.
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.
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.
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.
To request a refund:
  1. Create a support ticket with category refund_request via the Tickets API or the merchant dashboard
  2. Include the payment_id of the payment to be refunded
  3. The support team will process the refund and update the payment status
  4. You will receive a payment.refunded webhook when the refund is complete
Refund amounts are deducted from your merchant balance (available_amount decreases). Only completed deposits can be refunded; payouts and payments that are still pending or processing are not eligible.

Handling Status Changes

Use webhooks for payment updates and the status endpoint to reconcile missing or uncertain results. Respect rate limits when polling.

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

Pass external_id inside the customer object to link payments to your customer records:
external_id must be unique per merchant. If you attempt to create a new customer with an external_id that is already assigned to another customer within the same merchant account, the request will fail.

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 uses transaction_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 unique merchant_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.