Payment form in the wrong language and country in your app

A customer opens your app in English, reaches the last step of a purchase, and the card form appears in a language they do not read. The billing country is already filled in, and it is not theirs. To finish, they have to work out unfamiliar fields or change something on the phone in the middle of paying.

That is what we were asked to look at for a client, and there were two problems behind the one complaint. There was also a third thing worth knowing: fixing the code is not the same as reaching customers.

What the business saw

Customers using the app in English were shown the card-adding form in another language, and the billing address came up with a different country already chosen.

From the customer's side this is a stop at the worst possible moment. They have already decided what they want, and the card step is where the money changes hands. A screen that no longer matches the rest of the app makes people hesitate, and a billing country sitting there pre-filled is easy to overlook or to leave wrong.

The goal set for us was narrow: a customer should be able to add a card without switching languages, and without filling in the billing address wrongly. We were also asked not to replace the pre-selected country with a different one without first finding out why it had been set.

Why this happens to apps like theirs

Your app's language and your phone's language are two different settings, and a payment form can follow the wrong one.

In our experience, an app lets a person choose a language inside the app, and separately the phone has a system language set in the phone's settings. The app's own screens follow the first. The card form, though, is usually a separate piece supplied by whoever handles your card payments, and it reads the device's setting instead.

That is why the same app can look English everywhere and open the payment step in another language. Nothing is broken exactly; two parts are reading two different settings, and nobody has told the payment form which one to prefer.

The billing country is a different matter. A card form can arrive with a country already chosen, and in our experience that value is often left over from earlier setup work rather than a decision anyone made deliberately, but the only way to know is to ask whoever built it. Either way, the customer never chose it and may not read it closely.

Both problems stay invisible until someone whose phone or card comes from elsewhere reaches that step. That is the kind of customer an app taking payments from abroad tends to meet: people paying from elsewhere, or residents whose phone was set up in another language.

What our engineers found

The payment form was opening in the phone's system language rather than in the language the customer had chosen inside the app, so the customer's own setting was being ignored.

The billing country was being pre-selected, and we did not establish why that country in particular was there. Because we had been asked not to swap it for something else without knowing the reason, we left that question open and removed the pre-selection instead. Nobody now has a country chosen for them.

We replied straight away, and the change was ready within a working day.

What we changed

The customer's language choice inside the app now decides the language of the card form.

• The payment form opens in English whenever the app interface is in English, even on a phone set to another system language. The choice made inside the app takes priority.
• Before a card is added, the customer is asked to choose the billing country themselves. No country is selected in advance.

Both changes were made in the mobile app and merged into the main branch of the code.

What came of it

The code analysis passed with no remarks, and both the app and the server test suites passed. The server interface stayed compatible with older versions of the app, which matters: customers who have not updated should not be cut off by a change made for everyone else.

The new version is not published in the App Store or Google Play yet, so customers with the app already installed still see the old behaviour. The fix exists in the code and not yet on their devices.

Getting it to them needs the release steps: signed builds assembled and uploaded to the stores, and the release registered on the server once it is published. Until that is done, nothing visible has changed for a customer adding a card today.

What you can check yourself

• Change your phone's system language to something other than your app's language, then walk through the card-adding step in your own app. If the payment fields arrive in the phone's language and not the app's, the form is following the device.
• Look at the billing country before you touch it. If a country is already filled in, ask whoever set up the payment step why it is there and whether it was meant for your customers.
• Ask your developer whether the fix is in the code or published in the stores, and which version your customers are running. These are different things, and only the second one changes what a customer sees.
• Check your app's store listing for the latest published version, and remember a phone only moves to it when the customer updates.
• Ask your developer to run the payment step on a phone set to a different language, with a card from a country that is not selected in advance, before the next release goes out.
• Ask whether older app versions still work after the change. If the server stops accepting what they send, those customers meet an error.
• Do not change payment settings, store listings or server settings yourself while a release is pending. Ask whoever looks after the app.

What to do next

After a fix like this, the useful question is not only whether it was done, but whether it has reached anyone. A change sitting in the code and a change a customer can see are two different things, and that gap is where the confusion usually starts.

Three questions will get you a clear answer from whoever looks after your app:

1. Is the fix in the code, or published in the stores?
2. Which version are customers running, and how do you know?
3. What happens to customers who have not updated?

If you take card payments in an app, those questions are worth asking before the next release rather than after a customer complains. Payment steps in mobile apps are the kind of work our engineers do for clients.