question

mlyon avatar image
mlyon asked David Marginian Deactivated edited

"404 not found" when getting/retrieving a charge immediately after creation (sandbox)

I've noticed that after I create a charge with the /v1/charges API endpoint, if I immediately attempt to get the charge, the /v1/charges/{id} endpoint returns "404 Not Found". If I force a delay of about 5 seconds between creating the charge and retrieving it, it works fine. Anything less than that returns the 404 error.

This seems odd to me, the API shouldn't be responding that the charge doesn't exist after it has been created. Is this a bug? Does this problem exist in the production API as well?

If this is by-design, what is the best way to handle this? I can put artificial delays in parts of my app, or I can continually poll the API before eventually giving up.. but neither of those seem like ideal solutions.

Any advice would be appreciated.

Thanks!

Sandboxe-commerce api
10 |2000

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

1 Answer

·
David Marginian avatar image
David Marginian Deactivated answered David Marginian Deactivated edited

I tried to reproduce this a few times and was unable to. Is it possible that this is a transient issue? Is there a reason why you are retrieving the charge immediately after making it? The charge is returned in the v1/charges response. The additional get seems unnecessary.

3 comments
10 |2000

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

mlyon avatar image mlyon commented ·

In this simple test case it is unnecessary, yes. It's just something that came up while I was testing some other things. However I noticed that I'm having the same problem if I try to capture a temporary authorization too quickly after the auth charge is created, or refund a charge too quickly.. basically any action on a charge.

In a real use case with an existing app currently built using Stripe (which we're attempting to integrate Clover into), we often do a temporary authorization first, and if that succeeds we immediately capture the charge, rather than charging/capturing in one action. I s'pose that may seem unnecessary as well, and I can try to explain why we do it that way, but I can definitely see that being an issue for us with Clover. I can think of other situations where separate processes/tasks may attempt to verify that a charge exists before displaying it or performing an action on it, and I can imagine these 404 responses causing issues.

Would it be helpful if I send you a simple PHP script to replicate the problem with my test IDs?

0 Likes 0 ·
David Marginian avatar image David Marginian ♦♦ mlyon commented ·

That's not necessary, I will try again tomorrow and engage the ecomm team if I can reproduce it.

0 Likes 0 ·
David Marginian avatar image David Marginian ♦♦ David Marginian ♦♦ commented ·

I was able to reproduce this and engaged with the ecomm team. Unfortunately, there is a bit of syncing that is going on on our end which accounts for this. In normal situations this should only take a few hundred milliseconds but there are times when it may take longer.

0 Likes 0 ·

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Welcome to the
Clover Developer Community