Skip to main content
Use this sequence to add eDaler to an account’s wallet through a supported payment provider. It covers providers that permit direct purchase without a signed contract. The HTTP requests have been checked against the server source; a complete test payment has not been run. Use the test provider and payment method described in the prerequisites.

​
Prerequisites

  • An Agent API session and wallet-operation privileges.
  • An approved Legal Identity that includes a country.
  • A provider enabled for that identity’s country and the wallet’s currency.
  • Provider confirmation that the environment uses test value, with a permitted positive amount and test payment method.
Send the following requests over HTTPS with your account’s exact host, JWT, and application URL as Referer. Replace every placeholder before sending a request.

​
1. Read the starting balance and providers

The balance response contains amount, reserved, currency, and timestamp. Record all four. Do not apply a cents-to-units conversion without the provider’s documented value convention. The provider response contains a Providers array. Map the selected provider’s fields as follows: An empty provider list means no discovered provider is available to this account in its current context. Ask the operator which provider is available for the account’s country and currency.

​
2. Retrieve provider options

Send the selected serviceId and serviceProvider:
This operation starts an options transaction. Record its id and use that GUID as transactionId to retrieve its current information:
The information includes id, state, started, serviceId, serviceProvider, and options. Depending on the provider’s stage, it can also include clientUrl and ended. Options can initially be null. Treat option fields as provider-defined data. If clientUrl requires user interaction, present the trusted provider page using your application’s reviewed redirect policy. Complete the provider’s required interaction before expecting a final result.

​
3. Review and initiate the purchase

Prepare the same provider identifiers, the accepted currency, and the approved positive test amount. Replace the quoted amount placeholder below with a JSON number. Review the provider, amount, currency, fees, and payment method with the user. Then explicitly initiate:
This calls Initiate Buy eDaler. The returned transaction ID is the purchase transaction, separate from the options transaction. Store it with the intended provider, amount, and currency immediately. The server can return before provider processing finishes. A successful HTTP response or browser redirect does not establish payment completion.

​
4. Observe the purchase

Use the purchase transaction ID in the same retrieval operation:
Use the same account that initiated the transaction. The API rejects a lookup belonging to another account. Confirm when your provider considers the payment settled. A balance change alone cannot identify a specific purchase when other transactions occur at the same time.

​
5. Reconcile and retain evidence

Compare the new balance and timestamp with the starting snapshot, the purchase’s reported amount/currency, and the provider result. Keep the transaction ID, observed states, timestamps, provider identifiers, and your application order ID together. The selected server implementation keeps these transaction objects in a temporary registry configured for one hour. Treat transaction lookup as an operational status endpoint, not a durable accounting archive. A later 404 is not proof that no payment occurred.

​
Recover from failures

The optional transactionId request field is not a documented idempotency guarantee. Do not automatically retry a purchase initiation when its outcome is unknown. Keep your application’s duplicate-submission controls separate from payment status.