question

mlyon avatar image
mlyon asked ·

Concerns about eCommerce API reliability

I've spent the last couple weeks playing around with the sandbox eCommerce API to possibly integrate into a client's website. I have quite a bit of experience with other payment APIs, however our client already has Clover POS devices at their retail locations so it seemed logical to try to integrate the Clover API using their existing Clover account vs another vendor, so that we can eventually integrate their POS hardware as well.

Unfortunately, our experience thus far, to be quite frank, has been pretty terrible. The eCommerce sandbox API is constantly throwing errors. I'm regularly seeing error 500 (internal server error), error 503 (service unavailable), error 504 (gateway time-out), error 400 (bad request, but then the message is "Error connecting to payment gateway. Please try again later"), and other weirdness. I can understand the occasional downtime, but these errors are happening on a frighteningly regular basis, and have been happening for the entire time that I've been evaluating the API.

I've been a web developer for over a decade and have used many APIs over the years, but honestly, I've never used an API that throws as many transient errors as Clover's API does. If my client didn't already have Clover POS hardware, I would have already abandoned it. This just doesn't seem acceptable for something as vitally important as a payment gateway.. we simply can't have this many issues with our payment system in production.

With that said, I'm curious if these are known problems currently with the sandbox API, and/or if the production API currently has the same reliability issues? I'd love to hear some honest feedback from other developers and their experience with the live API in this regard, so that I can hopefully continue moving forward with some peace of mind for myself as well as my client.

Thanks in advance.

Sandboxe-commerce api
10 |2000 characters needed characters left characters exceeded

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

David Marginian avatar image
David Marginian answered ·

We have been investigating these issues and a great majority of them are due to the payment gateway. As I have mentioned in other posts, sandbox hits an emulated gateway. The emulator is not fault tolerant and we have a limited number of connections to it. In production we hit a real gateway that is fully fault tolerant, etc. We have started the discussion on how we can improve the sandbox experience. Thank you for your input.

10 |2000 characters needed characters left characters exceeded

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

David Marginian avatar image
David Marginian answered ·

What is your app id?

4 comments
10 |2000 characters needed characters left characters exceeded

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

Did you mean "app id"? Our sandbox app ID is H5B5NTTATVM6E and our sandbox merchant ID is 3ASKGPJV42ZW1.

I have a test script that creates a card token, then creates a customer with that token (card saved-on-file), then creates a charge for the customer, then refunds the charge.

I just ran it. Card token created successfully. First attempt creating the customer, error 500. Second attempt, 504 Gateway Time-out. Third attempt creating the customer was successful. First attempt creating the charge, error 500. Second attempt creating the charge was successful. First attempt refunding the charge, error 404. Second attempt, error 404. Third attempt, 400 bad request. Fourth attempt, 400 bad request. Then my script gives up. :(

0 Likes 0 ·

Yes, that is what I meant, we will look into these failures.

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

Another consequence we've encountered with these errors is that occasionally when the API responds with an error such as 504 gateway timeout, the action actually did succeed on the Clover side. So even though our client code is written to re-try on errors, it will still fail in these cases, or worse. For example, I've seen this happen when creating a customer with card-on-file. The API will respond with error 504, so our script retries, but at that point the card token has already been used (because the customer apparently was created?). So on our next retry, the API responds with error 402, with the message "You cannot use a clover token more than once unless it is marked as multipay". Since our code has no idea what the customer ID was from the first call, there's no easy way to handle the error. If this were to happen when charging a card-on-file, we would end up unknowingly with duplicate charges, which would obviously be a major problem.

0 Likes 0 ·
Show more comments

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