Listing Payments

Every payment you create — hosted checkout, direct API, marketplace split — is queryable through the same two read endpoints: GET /payments for filtered lists and GET /payments/:id for the full detail of one payment. Use them for dashboards, reconciliation jobs, customer-service lookups and order-state checks.

Both endpoints use plain Bearer authentication with your server-side access token (at_live_…) — no request signature is needed for read-only calls.

List payments

GET /payments returns a paginated list, newest first. Filters:

Rows related to a split payment carry a split field: splitPaymentId, role (PARENT main payment, LEG part) and, on a part, parentPaymentId and legSequence. Details: Split Payments › Listing and detail.

curl "https://api-gateway.lunixi.com/api/v1/payments?status=CAPTURED&customerId=cus_8f2a9c&page=1&limit=20" \
  -H "Authorization: Bearer at_live_5f3e2b1a..."

Response

{
  "status": "success",
  "code": "PAYMENTS_LISTED",
  "data": {
    "data": [
      {
        "id": "9c6f2b1a-4e8d-4a3f-b5e6-2d7c1a9b8e30",
        "amount": 10050,
        "currency": "TRY",
        "merchantId": "m_…",
        "status": "CAPTURED",
        "createdAt": 1780740000000,
        "updatedAt": 1780740002500
      }
    ],
    "total": 137,
    "page": 1,
    "limit": 20,
    "totalPages": 7
  },
  "statusCode": 200,
  "requestId": "…"
}

List rows are compact — id, amount (minor units; the charged amount, installment fee included), currency, merchantId, status, createdAt/updatedAt (epoch milliseconds). Fetch GET /payments/:id for the full record.

Get a payment

GET /payments/:id returns the full payment record, including its attempts and a summary of the route decision.

• Attempts — a payment may be tried more than once (for example when smart routing fails over to another provider credential). Each attempt records its outcome, so you can see exactly how the final state was reached.
• Route decision — a qualitative summary of why the payment was sent where it was sent: which routing outcome applied and whether a failover occurred. Internal scoring details are not exposed.

curl https://api-gateway.lunixi.com/api/v1/payments/pay_9f3a1c \
  -H "Authorization: Bearer at_live_5f3e2b1a..."

Response

{
  "status": "success",
  "code": "PAYMENT_FOUND",
  "data": {
    "id": "9c6f2b1a-4e8d-4a3f-b5e6-2d7c1a9b8e30",
    "amount": 10050,
    "currency": "TRY",
    "merchantId": "m_…",
    "status": "CAPTURED",
    "createdAt": 1780740000000,
    "updatedAt": 1780740002500,
    "orderId": "ORD-84722",
    "paymentChannel": "WEB",
    "locale": "tr",
    "installment": 1,
    "is3D": true,
    "metadataJson": "{}",
    "description": "Order #84722 payment",
    "providerCode": "…",
    "attemptCount": 2,
    "recoveredAfterRetry": true,
    "recoveryAttemptCount": 1,
    "recoveryProviderPathJson": "[…]"
  },
  "details": {
    "capturedAmount": "10050",
    "refundedAmount": "0",
    "remainingCapturable": "0",
    "remainingRefundable": "10050",
    "events": [ "…payment event timeline…" ],
    "routingSummary": { "…qualitative route decision…": "…" },
    "attemptHistory": [ "…one entry per charge attempt…" ],
    "card": { "…masked card info…": "…" },
    "threeD": {
      "mode": "…",
      "liabilityShiftGranted": true,
      "post3DFailoverUsed": false
    }
  },
  "statusCode": 200,
  "requestId": "…"
}

The data block is the payment record itself; the details block adds the settlement amounts (capturedAmount, refundedAmount, remainingCapturable, remainingRefundable — minor-unit strings), the event timeline, the attempt history and the routing/3-D summaries.

Payment statuses

The status field always carries exactly one of these 12 values:

A chargeback does not overwrite the financial status — dispute state is exposed through the payment.disputed webhook and the Chargebacks surface, while the payment stays CAPTURED/REFUNDED.

Analytics

Two read-only analytics endpoints (Bearer) complement the list:

• GET /payments/analytics/failover-recovery — how often smart routing recovered a payment by failing over to another route: recovered volume and counts over your traffic.
• GET /payments/analytics/provider-credentials/:id — performance of a single provider credential (the :id is the credential you configured in the panel): success rates and volumes attributed to it.

Both are aggregate and qualitative — they report outcomes, not the internal routing model.

Errors

Next steps

• Webhooks — get pushed the same state changes instead of polling
• Pre-authorization, Capture & Void — act on AUTHORIZED payments
• Refunds — act on captured payments
• Chargebacks — what happens after payment.disputed