Skip to main content
Once your user submits a crypto transaction you will be able to fetch the transaction details. But how exactly do you know when the transaction has been created and when the information is ready to be fetched? This page details exactly how and when to fetch transaction details.

​
Webhooks

The recommended way to receive updates about transactions is by signing up to receive webhooks from Meld. You can find out more information about the specific webhooks you’ll receive for crypto transactions here, with a summary below.
  1. Meld will send you a TRANSACTION_CRYPTO_PENDING webhook to let you know that a transaction now exists in the Meld system and is PENDING. This webhook returns a transactionId that you can use at this time to fetch the transaction details from Meld’s get transaction endpoint.
  2. As the transaction proceeds through the lifecycle (most common path is PENDING -> SETTLING -> SETTLED, Meld will send you a TRANSACTION_CRYPTO_TRANSFERRING webhook to let you know the transaction is PENDING and ultimately a TRANSACTION_CRYPTO_COMPLETE webhook if the transaction succeeds or a TRANSACTION_CRYPTO_FAILED webhook if the transaction fails. You should use each of these webhooks as a trigger to fetch the latest transaction details from Meld’s API.

​
Polling

If you are not signed up to receive webhooks from Meld, you can poll Meld’s search /transactions endpoint at an interval to keep track of new transactions. The downside of using polling is that there is latency, there will likely be a noticeable delay between the transaction updating on Meld’s side vs your side. But if you poll too frequently it will take up considerable resources and Meld will reach out to you to discuss this. For this reason, Meld recommends using webhooks, and then having a batch job poller that runs infrequently as a backup to pick up any transactions for which webhooks might’ve been lost.

​
SessionId / ExternalSessionId / CustomerId / ExternalCustomerId

This section is generally only applicable to polling. When you hit Meld’s /widget endpoint to create a widget url, in the response you will get back a sessionId and customerId. You can also pass in an externalSessionId and externalCustomerId. You can use any of the above 4 params from that response as a query param in the search /transactions endpoint to get back all transactions related to that id. However, there may not actually be a transaction tied to that id. The reason for this is service providers (and Meld) do not create a transaction just for generating a widget url or even launching that url; typically, users have to do something significant within the widget (such as passing kyc / login) for the service provider to create the transaction on their end, which then triggers Meld creating the transaction on its end. Therefore Meld recommends not searching by these ids unless necessary, as the other two methods are more reliable.

​
Transaction Statuses

See here for more details on the various Meld transaction statuses. Once a transaction is in a terminal status its status will not change, and the details of that transaction won’t change either.