Server error when buying a subscription

I now have 2 customers who got a “server error” when trying to buy a subscription via the link associated with the subscription plan I created. I tried to buy it myself (as a test) and that worked.
Still,… its very strange that I suddenly have this.
I never had this in last 10 month.
It also looks like I have much less sales in last weeks than before.
So… has something changed with the creditcard checking?

Note I also “deliberately typed the wrong cvv” just to test → that indeed did create a “server error” message but NOT a “wrong credit card info” message as I was expecting.

Please help solving this.
Note: this is seriously hurts my business, I cannot afford to operate long in this state.

:wave: Is this with our Checkout Links? If so what’s the link your customers are using? :slightly_smiling_face:

With checkout links indeed:
[link removed]

I noticed that “zip code” is a new mandatory checkout field. I kind of have the feeling the problems started when that field was introduced.

I was able to replicate and have escalated to the team. :slightly_smiling_face:

Ok, thanks,
Hope this gets priority, this is really costing business.
Note: I removed the link from above post, if you need it back I can put it back or send private message.

As you were able to reproduce:

  • What are the conditions this happens?
  • What is the way to prevent this from happening?

Any update on when this gets solved?

Unfortunately, we don’t have an update on a fix however this happens when payments are declined or incorrect card information was entered. Customers should double check their card information and try to submit payment again. :slightly_smiling_face:

OK thanks. That helps. At least now I can tell people that “server error” in fact means “card declined”.
Still hope it gets fixed soon.

Any update on this?
Yesterday an other 2 clients that could not complete their payments.
This is costing me business!

Checking with the team. :slightly_smiling_face:

Any reply from the team?
Looks like I’m loosing an other customer and/or looks like I’m pushed towards PayPal.

For your info:

  • this is in UK
  • looks like some credit cards have this problem, others not

Any progress on this?
Note, As you can see in below screenshot I notice that the default phone-prefix provided in checkout is +1 (US) which strange since my shop is in UK (as you can clearly see the prices in pounds) which has prefix +44

According to this thread:
A/ This has been a huge reason for failed orders in the past underlining my input.
B/ This should have been solved by now; latest reply is from square-bernadattea 3 weeks back

Can you please comment?
Was this indeed solved few weeks back? Is this error re-introduced with some update? Any plans to (re)solve this?

Can you post the link in that screenshot?

Dear Rchen,
Thanks for reacting.
here you go:

This link shows as below when opened in UK.
As you can see the phone number has country prefix +1 (US), not +44 (UK)

(links & screenshots at bottom of message)

I’m highly confused:
1/ All checkout links I have in active use have been created with checkout links from the square seller dashboard: Sign In
==> I have been doing this for more than a half year now.

2/ I checked available checkout links using GET to
==> to my surprise NO checkout links were found

3/ then created a checkout link using a POST to
==> this link IS found with a GET request

4/ then (test)ordering a subscription with that link.
To my surprise:

  • checkout page is completely different form the checkout page resulting from the checkout-link that was created via the dashboard
  • Now the phone number indeed correctly defaults to UK prefix in stead of US prefix.
  • after order, the subscription is correctly administrated as an additional subscription (good!)
  • however: the link appears to be a ONE TIME USE link, so… it can only be used for 1 transaction for 1 customer. Clicking after use the link reports “order complete”. So,… it CANNOT be used as a button on my website to order the subscription.

Well… this now raises several questions…
A/ How should I proceed in getting a checkout link for the subscription plan? method described in is not not providing a link that can be used for a “buy button” since it provided a 1-time use link only.
B/ On the other hand, the link provided by the seller-dashboard results in an unreliable checkout experience.
C/ Any change that the square-seller-dashboard gets upgraded such that the checkout experience becomes reliable?
(note: so far I have been using the square-seller-dashboard for 90% of actions and made a small additional php application to handle functions I missed in the seller dashboard, having this fixed in the seller dashboard would highly reduce my ITwork)

So… what should I do?

Links referenced:
Checkout link in active use created with Sign In
Phone prefix is +1 (US) in stead of +44 (UK)
I Like Singing

Checkout link created for testing using POST to
Phone prefix is +44 (UK) which is correct. layout completely different
I Like Singing

Screenshot of Checkout link in active use created with Sign In
Phone prefix is +1 (US) in stead of +44 (UK)

Screenshot of Checkout link created for testing using POST to
Phone prefix is +44 (UK) which is correct. layout completely different

The links created via API are one-time links (they cannot be re-used after the buyer checks out successfully), while the links created in Square dashboard can be used multiple times for multiple buyers.

The checkout page for one-time links is using a new and revamped UI. This UI is also available for the re-usable links created in Square dashboard, but ONLY in the US as of now. We plan to release this for other countries (including UK) in the near future. Once we do, the country code phone number issue will be automatically resolved (as you’ve already noticed).

I think what you’re doing is already correct (creating subscription links via Square Dashboard so that they are re-usable); simply wait for the new UI to be released in the UK and your issue should be resolved.

Dear Rchen,
Thanks for this update.
To be clear: I do not know whether the original problem was caused by phone-number prefix.
I did some testing and actually in case of wrong prefix the checkout-form nicely alerts “phone number incorrect” before form is send.
Still… some users get consistent “server error” when they try to subscribe using the multi-use-checkout-link as created with the square application.

As a containment I generated a small serverside app that uses the payment-links-api to generate a one-time-use checkout link. I can send that to my customer in cased the published multi-use link on my webstore keeps failing.

We’ll see how this goes.

  • in case I have a customer that keeps having problems I can send a one-time-use link
  • I kind of “hope” the one-time-use link will not have the same problems
  • Looking forward to the moment the new checkout-experience comes available for multi-use (wegstore) checkout links with which the problems are than hopefully fully solved.

Dear @rchen,
Since last time I did write certainly things changed.
I noticed that the subscription-checkout-link that is generated in the square online dashboard is now also updated to new layout. phone number is now showing a UK-prefix: GREAT!

Unfortunately problems are not over.
About 4 out of 5 times we have no problem.
But about 1 out 5 the link is not functioning.
I did get a screenshot from a customer on his problems (normally customer do not send that so I’m very happy!)

Please find screenshot below. I did mask all inputs for privacy reasons but can send you an unmasked one in private message if that helps. In short: all field were filled quite ok.
Error message is: “We are unable to complete your request at this time. Please try again”

Problem occurred with this link:

Hope this helps.

1/ At this moment we have to manually create a subscription via the squareup dashboard in all cases the link does not work. Although this is a containment I’m afraid we loose customers who think us to be “dodgy” if they see the checkout link failing repeatedly.
2/ The problem occurs about 1 out of 5 times on subscription checkout link, atbteh same time we have not had any complaints on invoice handling. So… I would say the issue is related to the simultaneous creation of customer/subscription&invoice.
Could it be a timing issue (that subscription is added before customer is written to database or something alike)?
3/ We made a small serverside app that can setup a subscription without using the squareup dashboard using the “” endpoint but that seems to give error in most cases the squareup-dashboard link fails.

Thanks for looking into this


@rchen , @Bryan-Square,

Can you please provide an update on this issue?

  • We now have this going on for 2.5month without much progress.
  • We DO have a containment but it is very unprofessional that 20% of our customers get an initial refusal and need to be processed manually after that.

We would like to know:

  • Does this get a solution? If so, by what approximate time?
  • Or is a solution unlikely in near future and should we look for an alternative?