Life Cycle

What happens to your payment once you submit it to Devengo? Learn it here.

When you need to send money through Devengo, you make a simple POST request, but this is just the start of a journey for this payment inside our system. We will try to explain it in this guide.

But before we start, it's important to remark that all this happens asynchronously. Yep, that means that when you do your POST request, our response only implies that the payment has been accepted, and in this response, you will receive the payment's ID that you will be able to match seconds later with the notifications you will receive every time your payment enters a new state.

States of a payment

Payments life cyclePayments life cycle

Created

The initial state of any payment is created. Before its creation Devengo checks that all the provided information is syntactically valid (well-formatted IBANs, valid currency, etc.) so your payment has passed that first filter, congrats! However, the payment processing has not started yet, and semantic validations (AML checks, established custom limits, etc) may still make your payment to be denied.

Interestingly, with this event, you will receive the payment's ID, the selected payment processor (SCT or SCT-INST), and an ETA (Estimated Time of Arrival) when the third party should receive the money.

Webhook sent: outgoing_payment.created.

Validating

validating is the state when Devengo performs business and banking validations: defined business limits, etc. If your payment is valid, it will be waiting for its turn in our processing queue in a pending state. If it doesn't pass the validations, your payment life will end in our denied state.

Webhook sent: outgoing_payment.validating.

Blocked

Sometimes, and for a few transfers, Devengo will need to make some extra banking verifications (like AML checks and others) and block the payment in order to finish this process. If your payment passes the verification it will continue to the pending state. If not, your payment will go to the denied state.

Webhook sent: outgoing_payment.blocked.

Delayed

Very sporadically, we may have to stop the delivery of payments to the banking infrastructure as it may be undergoing a maintenance window or suffering an unexpected downtime. In that situation, all affected payments will see their state moved to delayed. Once the infrastructure is back up, we will automatically deliver these payments, moving them to pending

Webhook sent: outgoing_payment.delayed.

Pending

Your accepted and valid payment is waiting to be processed. Don't worry; it won't wait long.

Webhook sent: outgoing_payment.pending.

Processing

Your payment has been sent to the banking system. This is the point of no return, and your payment can't be canceled once this point is reached.

What happens after this point depends on the processor of your payment.

  • SCT-INST: you will know what happens with your payment in less than 10 seconds. If it has been credited to the destination bank account, it will go to confirmed; if it hasn't, it will go to rejected. There are many reasons a payment cannot be delivered (account blocked or closed, the account holder is dead, etc.), and you will receive the exact reason.

  • SCT: if the payment has been accepted, it goes to confirmed, but given how the banking system works, it doesn't mean the money has been received; it should arrive on the next banking day (remember you get an ETA on creation!). If the money can't be delivered, your payment will change to a reversed state between 1 and 7 days later. Yep, the banking system says the payment has been confirmed, and a few days later, they will say it wasn't. Sorry, we promise it is not our fault.

Webhook sent: outgoing_payment.processing.

Confirmed

Depending on the processor, it means:

  • SCT-INST: the money has been delivered to the destination bank account. In this case, it is a final state.
  • SCT: the money is in the banking system, going slowly to the destination bank account. In this case, this is an almost final state.

You might ask why we use confirmed in the case of SCT instead of something different, and the reason is that we will never get confirmation of this payment, just errors if they appear. But don't worry, those are not common.

Webhook sent: outgoing_payment.confirmed.

Rejected

This is the final state for an SCT-INST payment that couldn't be delivered.

Webhook sent: outgoing_payment.rejected.

Reversed

This is the final state for an SCT payment that couldn't be delivered. Remember, it comes from confirmed.

Webhook sent: outgoing_payment.reversed.

Denied

This is the final state for a payment that didn't pass the validations performed during the validating state.

Webhook sent: outgoing_payment.denied.