Skip to content
Cashela Cashela Cashela API

Search is only available in production builds. Try building and previewing the site to test it out locally.

Integration flow

A deposit always follows the same sequence. Steps 1 and 2 can be cached briefly; step 2 should be repeated before each deposit because fees, availability and required fields can change.

Sequence of a Pay-In deposit between your customer, your server, the Cashela API and the Cashela payment pageYour customerYour serverCashela APICashela payment page1. GET /deposit-creation/countriescountries2. POST /available-payment-methodsmethods, fees, required fields3. choose a method, enter payer datapayer data4. POST /deposit-creationPROCESSING + payment link5. redirect to the payment link6. paysback to your redirect_url7. signed notification2xx8. GET /transactions/{reference}

Step by step

  1. List countries. GET /api/v1/pay-in/deposit-creation/countries returns the countries available to your account in the current environment. See Get countries.

  2. List payment methods. POST /api/v1/pay-in/deposit-creation/available-payment-methods with the country and amount. Each option gives you the payment_method code, the fees, the total your customer pays, what is credited to you, and the customer fields required for that method (mandatory_fields, required_fields, document_types). See Get payment methods.

  3. Collect the customer’s data. Build your form from the chosen option’s required fields. See Payer data & documents.

  4. Create the deposit. POST /api/v1/pay-in/deposit-creation with your unique external_identifier and, optionally, an Idempotency-Key header. See Create a deposit.

  5. Send your customer to pay. If the response carries a payment link (data.details.paying.metadata.redirect_url), redirect your customer to it or open it in a new window. Otherwise, show the payment instructions. Card payments always use the Cashela-hosted payment page; see Card payments.

  6. Your customer pays before the link expires (validity_period). Afterwards they return to your redirect_url.

  7. Receive the notification. When the deposit reaches a final status, Cashela sends a signed POST to your notification_url. Verify the signature, update your order, and answer 2xx. See Webhooks.

  8. Reconcile. Read the deposit with GET /api/v1/pay-in/transactions/{reference} whenever you need to confirm its status or amounts. See Get a deposit & statuses.

Deposit lifecycle

Deposit statuses: ONHOLD, PROCESSING, INREVIEW, then COMPLETED, DECLINED, CANCELLED or FAILED; a COMPLETED card deposit can become REVERSEDdocument reviewpaidrejectedcancelled or expiredfull void / refundcreation failedONHOLDINREVIEWPROCESSINGCOMPLETEDDECLINEDCANCELLEDREVERSEDFAILEDGreen: money credited · Red: no money moved · Amber: money returned

COMPLETED, DECLINED, CANCELLED, FAILED and REVERSED are final. See statuses for the full table.

Production checklist for this flow

  • Call Get payment methods before each deposit; never hard-code method codes or fees.
  • Store your external_identifier before calling Create a deposit, so a retry uses the same one.
  • Verify every notification’s signature, and process each deposit’s final status only once.
  • Treat the return to redirect_url as navigation only.
  • Reconcile money only on COMPLETED (and REVERSED).