API keys
Every request is authenticated with your secret API key, sent in the X-Api-Key header:
curl https://payments.leffelconsulting.com/v1/payments/lcpay_9f2c... \
-H "X-Api-Key: lc_live_XXXXXXXXXXXXXXXXXXXX"An Authorization: Bearer <key> header is also accepted. Keys look like lc_live_….
Keep keys secret
API keys are server-side credentials. Never ship them in browser code or a mobile app, and never
commit them to source control. A missing or invalid key returns 401 Unauthorized.
Keys are stored only as a salted hash on our side — we can’t show you a key again after it’s issued, so store it securely when you receive it. Keys can be rotated and revoked without downtime.
Idempotency
Creating a payment is a mutating operation, so POST /v1/payments/intents requires an
Idempotency-Key header. This makes retries safe — a dropped connection or a client retry never
creates two charges.
curl https://payments.leffelconsulting.com/v1/payments/intents \
-H "X-Api-Key: lc_live_XXXXXXXXXXXXXXXXXXXX" \
-H "Idempotency-Key: order-10432" \
-H "Content-Type: application/json" \
-d '{ "amountCents": 4999, "currency": "usd" }'- Use a key derived from your order id (stable across retries).
- Retrying with the same key and body returns the original response — no new charge.
- Reusing the key with a different body returns
409 Idempotency conflict. - A request still in flight returns
409 In progress— retry shortly.
Note
There is also an optional idempotencyKey field inside the request body. That one is forwarded to
the payment processor as its native idempotency key — it’s separate from the Idempotency-Key
header, which governs our own replay cache. Using the header is enough for most integrations.
Next: Onboard a merchant.