Skip to content
Start for free
In pilot scope

Take payments with one API and get a verified result.

Your server opens a payment session with the order amount and reference; the customer picks an instalment plan on a mobile-friendly payment page and enters the card on the provider's secure page. The result is confirmed by querying the provider.

Start for freeDeveloper docs

The API and test environment are in pre-pilot preparation; live use opens once the business application is approved.

Payment sessionSample data
curl https://api.efespay.com/v1/payment-sessions \
  -H "Authorization: Bearer $EFESPAY_SECRET_KEY" \
  -H "Idempotency-Key: order-1001" \
  -H "Content-Type: application/json" \
  -d '{
    "order_reference": "ORDER-1001",
    "amount_minor": 125000,
    "currency": "TRY",
    "installment_options": [1, 3, 6],
    "return_url": "https://shop.example.com/order/1001"
  }'

Response (201)

{
  "id": "ps_…",
  "object": "payment_session",
  "status": "open",
  "url": "https://efespay.com/pay/ps_…",
  "payment_id": "pay_…"
}

We handle the hard part of the payment flow.

Different provider APIs, callbacks and error codes come together in one contract.

  • One contract

    The same request and response format for every provider: snake_case fields, amounts in minor units.

  • Verified result

    A browser return does not mark a payment as successful; the result is read from the provider server-side.

  • No double payments

    Idempotency-Key and order reference protection prevent a second open payment for the same order.

  • Uncertainty is its own state

    If the provider does not respond, the payment is not marked as failed; it stays "verifying" and is queried automatically.

How does it work?

From order to verified result in four steps.

  1. Step 1: Open a session

    Send the amount, order reference and instalment options with POST /v1/payment-sessions.

  2. Step 2: Redirect the customer

    The url in the response takes the customer to a payment page shown under your business name.

  3. Step 3: The customer pays

    The card is entered on the provider's secure page; 3D Secure is completed when needed.

  4. Step 4: Get the result

    A signed webhook arrives; you can verify any time with GET /v1/payments/{id}.

What happens after the payment is in the same API.

Refunds, partial refunds and cancellations work on the same payment record. Every provider call is kept as a separate attempt and shown in the panel and the API with its routing reason.

  • Full and partial refunds; total refunds cannot exceed the captured amount
  • Cancellation (void) where the provider supports it
  • Test mode and scenario-based test cards
  • Signed webhooks and an event log
  • Business name, colour and support contacts on the payment page

Related solutions

All solutions

Frequently asked questions

Send us your question
Do card details pass through Efespay?

No. Card details are entered on the provider's secure payment page; neither Efespay nor the business sees the card number. Efespay only keeps the masked summary returned by the provider (BIN, last four digits).

Is the payment successful when the customer returns to my site?

No. A browser return is not proof on its own. Update the order from the webhook or from the verified status in the GET /v1/payments/{id} response.

What happens if the provider does not respond?

The payment is not marked as failed; it moves to "verifying". Efespay queries the provider at intervals; once the result is final, the status is updated and a webhook is sent.

Let's try the integration together in test mode.

Describe your current payment flow; let's plan how to connect the API with test keys.

Start for freeDeveloper docs