Payment Types when paying a basket

You're still overriding it by its original key. That will always take priority. Also do not edit override files directly. Use the language overrides tab when editing a language plugin in CB > Plugin Management instead. So you'll want to remove the language override on COUPON_adb6e6 key and instead use the following.

Key: Coupon
Text: Postal Order

Anytime you see a hash after a language key it means it's a generated language key. So it doesn't technically have a language key and it tends to work best when you just override it by it's existing text if possible.

I deleted all my language overrides using plug-in management (I don't edit files direct unless it is absolutely necessary) and followed the example you supplied.

This led me to understand now that you don't edit the text of an existing language string. Instead you create a new override using the text you want to override as the key, and add the new string as the override text. Do I have this right?

It seems to work just fine for populating the dropdrown Payment Type box when recording a payment (from either the front- or back-end).

So I created three overrides as follows in the Default Language file:
1) Key: Fax payment, Text: Card (Chip&PIN or contactless)
2) Key: Post transfer, Text: Standing Order
3) Key: Phone payment, Text: PayPal Send Money

Then I did three renewals and payments (using the three different payment types) to bring a long-expired member up-to-date. The attached images show how the invoices and payments are displayed – the override texts have not been used.

So I still have the original problem of displaying the incorrect value when viewing invoices or payments.
(I don't know where the spurious fourth payment line came from)

I also looked at the rows in the cbsubs_payments table and for all the payments the payment_type is the value displayed, not the override value.

Should I have updated the overrides for the EN-GB plugin in the same way? It currently has no overrides.

This led me to understand now that you don't edit the text of an existing language string. Instead you create a new override using the text you want to override as the key, and add the new string as the override text. Do I have this right?

Correct.

Then I did three renewals and payments (using the three different payment types) to bring a long-expired member up-to-date. The attached images show how the invoices and payments are displayed – the override texts have not been used.

You only overrode the dropdown labels. Add language overrides for exactly what you see in that column. So the below is what you'd also override.

Key: post
Text: Standing Order

Will review seeing if some improvements can be made to the payment type selector.

forge.joomlapolis.com/issues/8646

Have also made note to review adding support for a custom payment type option to supply whatever payment type text you want.

I also looked at the rows in the cbsubs_payments table and for all the payments the payment_type is the value displayed, not the override value.

It doesn't store the label, which is translated. It stores the value.

Thank you - that fixes it for the invoices display on the front end and on the individual invoices, but it still shows 'post' on the backend Payments page (List of payments received).

Do I need to do something else?

I have tried adding another override for 'Post' in case the key is case-sensitive but that had no effect on what is shown on the backend Payments page. We can work round this using the Transaction Id if necessary.

Thank you for having such enormous patience with me - I am truly grateful.

Bankend display just maybe flat out not sending through translations. Will be reviewing the entire chain of usage for payment type when I get to that feature ticket. As is it's a pretty useless metric given it can't be customized or translated easily and that's primarily because it's a value expected from the payment gateway of which you'd normally have no control over.

Thank you for clarifying that. We can live with it and work round it for internal use. It was important that I learned how to do the overrides correctly so that we present accurate information to the membership, and I am very grateful for the time and trouble you have taken in answering my questions. I have documented everything I have learned in the course of this thread and saved it for future reference.