Why this endpoint exists

Payment status, straight from the platform's record, including the provider's own transaction reference. It answers the reconciliation question — "what happened to this payment, and what is it called at the provider?" — which the checkout status alone cannot.

For the ordinary purchase flow you do not need it: GET /checkouts/{checkout_id} tells you whether the customer paid, and that is what your storefront should poll. Reach for this endpoint when you are matching platform records against provider statements, or when support needs a PSP reference to look up a transaction.

Request

curl "https://api.acc.funtrips.io/v2/me/payments/$PAYMENT_ID" \
  -H "x-campaign-id: $CAMPAIGN_ID" \
  -H "Authorization: Bearer $END_USER_TOKEN"

Response

{
  "data": {
    "payment_id": "c8f3a2e1-7b54-4d69-9a03-1e5c8f2b7d40",
    "order_id": "5e2a7c91-3b6d-4f82-a17c-9d4e6b1f3a25",
    "amount": { "value": "52.97", "currency": "EUR" },
    "status": "SUCCESS",
    "psp_reference": "8836271094523841"
  },
  "meta": { "correlation_id": "…" }
}

psp_reference is the field that makes this endpoint worth calling: it is the identifier the payment provider itself uses, so it turns a customer query into a lookup rather than a search.

Payment status versus checkout status

They are different state machines and they can disagree briefly.

The last row matters: a refund is recorded on the payment, not by rewinding the checkout. A refunded order still reads SUCCESS as a checkout. If you display refund state, read it from here, not from the checkout — and expect the corresponding fulfillment order to be REFUNDED with its tickets voided.

Where payment_id comes from

Not from any retailer-facing response. Confirm returns order_id, order_display_id and payment_url — no payment id.

So in practice you arrive here holding a payment_id from a support ticket, an internal record, or a report. If your goal is "did this order get paid", start from the checkout or the fulfillment order instead; those you can reach from ids you already hold.

Errors

Notes

• Amounts are decimal strings. "52.97", not 5297. The platform's own provider integrations work in minor units internally, but this API always presents decimal strings with an explicit currency.
• Refunds are not initiated here. Customer refunds are a back-office operation, not a retailer-facing one.