Webhook issues

So I have an a personal project that consumes from the monzo API and receives all my transactions via a webhook. It’s all working fine but I receive each transaction multiple times. The documentation says it will keep trying if it doesn’t receive a successful response, which I guess is what’s happening, but I am returning 200 and I don’t see any details to say that is incorrect. Does anyone know what I need to do to confirm receipt of a webhook? Or is it always going to send it multiple times?

I’ve worked around it for now, but it would be good to stop it wasting network calls.

Hi Tom,

Are the multiple transactions received in quick succession, or are they hours/days later? I had the same issue when I set up my webhook and discovered some transactions are sent twice, once when they’re created (settled = ,) (empty), and then again with the date when they are settled. I now check for a value in settled before I used the data.

My webhook returns a 302. I certainly don’t respond with anything in particular, and don’t get multiple attempts from the webhook.

They are in quick succession, I am guessing its part of the retry and back-off process. Its quite strange. I need to spend some more time investigate it. Its just occurred to me I never delete a webhook but create a new one every time I launch the app, so maybe I have multiple registered. I will check that out!

1 Like

Yep, that’s a likely cause.

I’m also working with webhooks and have them all set up relaying incoming transaction data to my server. Everything is working great, but I have a question about the data.settled value in the payload:
Unlike the data.created value, the time given in the payload is not the time as of the payment, or even a delayed payment. The time I receive for this is always a fixed very regular time.

For example for two payments that have data.created values of 09/10/2019 11:07 and 09/10/2019 10:52, I received that for both the data.settled time = the arbitrary time of 09/10/2019 13:45.

In fact, the settled time given is always one of the following three no matter when the payment was received:
08:00
16:30
13:45

Does anyone know what is going on here?

Is this something to do with the Mastercard clearing cycles possibly? I think they’re at specific times of the day so it would make sense if it were that.

My webhooks are relaying data from incoming bank transfers so it shouldn’t be related to Mastercard clearing cycles. I did wonder if Monzo have a similar sort of clearing cycle arrangement though, but this doesnt make sense since I can immediately withdraw the funds to another account

Ahh sorry, didn’t spot that this was about incoming bank transfers. I’m guessing you’re right though - hopefully someone from Monzo spots this and can help.

No worries, thanks for your response!

1 Like

Do you know how I might be able to contact the Monzo developers directly?

Hi,I’m working with webhooks and have them all set up relaying incoming transaction data to my server. Everything is working great, but I have a question about the data.settled value in the payload:
Unlike the data.created value, the time given in the payload is not the time as of the payment, or even a delayed payment. The time I receive for this is always a fixed very regular time.

For example for two payments that have data.created values of 09/10/2019 11:07 and 09/10/2019 10:52, I received that for both the data.settled time = the arbitrary time of 09/10/2019 13:45.

In fact, the settled time given is always one of the following three no matter when the payment was received:
08:00
16:30
13:45

Does anyone know what is going on here? I need to know what time are the payments actually settled, and securely in my account.

Is this something to do with the Mastercard clearing cycles possibly? I think they’re at specific times of the day so it would make sense if it were that.

Just replied on the other thread you posted this on. Probably best to keep it all in one place.

2 Likes

Hi @embed, I’ve moved your topic into this thread to keep the conversation together.

Bacs also has clearing cycles where Monzo uploads a file containing all their processed faster payments and direct debits.

I’ll see if I can find a thread that has more information about it.

@Rika might also be able to shed some light :sparkles:

2 Likes

Yep you’re right, should keep it all to one

Great thanks dan. Does this mean that it isn’t until the specified settled time that the payment is regarded as finalised?

At what point can I be sure that the money is actually within my account and cannot be reversed (obviously apart from special circumstances)?

You should ignore the settlement timestamp, particularly for credits from schemes like Bacs or Faster Payments. Honestly, the fact that it is still present in our API is a bit of a throwback, and I wouldn’t be surprised if we removed it in the future.

From the point of view of your balance, the “settled” timestamp is basically irrelevant, as it represents different things depending on the scheme. It is partially useful for mastercard transactions, as an empty settlement timestamp means that we have only received an “authorisation” but not a “presentment”, and if it’s been a few days that means we’re quite likely not going to (so it’d reverse automatically after 7 or 30 days depending on the type).

For Faster Payments it’ll be fixed to the settlement time of the current faster payments settlement cycle, a point in time in the recent future. This is only useful for Monzo’s internal accounting.

Except for special circumstances, as soon as the transaction has been created (so a few milliseconds before the webhook fires).

By “special circumstances” I mean something going wrong like we took too long to respond to a faster payments message and receive a reversal instruction. This would be represented as a separate debit after the credit.

4 Likes

Thanks a lot Nick, for taking the time to respond to my questions in full, really appreciate it!

In that case, should I regard the data.created timestamp as the settlement time (for bank transfers)?

I need to be certain that the payment has been received before calling certain other functions in my project. What would you recommend as the best check/s to ensure this?

Does my receipt of this webhook itself guarantee that the transaction has already occurred (a few ms before as you stated)? Does the data.created timestamp confirm this specific time?

Would it be enough, in order to guarantee that the transfer has arrived, if I check for the existence of data.settled i.e. check that the value is not empty?
Thanks a lot for your help!

1 Like

In that case, should I regard the data.created timestamp as the settlement time (for bank transfers)?

Yep, though if there’s any clock skew between Monzo’s servers and yours then this timestamp might be out. I wouldn’t check the timestamp at all, though it may depend on your use-case.

I need to be certain that the payment has been received before calling certain other functions in my project. What would you recommend as the best check/s to ensure this?

The fact you’ve received a webhook means that this movement of money has already happened in our systems.

Would it be enough, in order to guarantee that the transfer has arrived, if I check for the existence of data.settled i.e. check that the value is not empty?

If a transaction has been created and a webhook has fired, it means that money has moved in or out of your account, regardless of whether or not the “settled” timestamp is populated or is set to a time in the future.

If you want to take some sort of action off the back of money arriving in the account (like move it into a pot), you should be prepared for the possibility of that failing because it is not possible to guarantee that that money will remain in the account. It’s very possible for some other transaction to happen in the same second that would reduce the balance.

1 Like

Meant to say data.created here - but thanks for the clarification that the webhook is only sent after the money has been transferred.

Understood, thanks for the clarification here.