Skip to content

Show the payment method in the customer's language in order e-mails and PDF - #942

Merged
KrzysztofPajak merged 2 commits into
developfrom
refactor/business-explicity-pr6b
Oct 18, 2026
Merged

KrzysztofPajak merged 2 commits into
developfrom
refactor/business-explicity-pr6b

Conversation

@KrzysztofPajak

Copy link
Copy Markdown
Member

Type: bugfix

Issue

Payment plugins translate FriendlyName with the current request's language. Business code reads it for the customer, though: the {{Order.PaymentMethod}} message token and the PDF invoice (whose other texts already use Order.CustomerLanguageId). When an admin changes an order status, or a scheduled task sends the e-mail, the customer gets the payment method name in the admin's or the default language. TaxService and ShippingService also translated the provider name just to write it to the log.

Follow-up to #940 (architecture backlog M1, PR 6b).

Solution

  • IPaymentProvider.GetFriendlyName(string languageId): a default interface method returning FriendlyName, overridden by BrainTree, Cash on delivery and Stripe Checkout with GetResource(key, languageId).
  • GetOrderTokensCommandHandler and OrderPdfTemplate.cshtml call it with Order.CustomerLanguageId.
  • Tax and shipping errors are logged with the provider's SystemName.
  • Left unchanged on purpose: IProvider.FriendlyName and IPaymentProvider.Description(). Only Web reads them, inside a request, where the request language is the right one.

Breaking changes

None. The new method has a default implementation; external payment plugins keep their current behavior until they override it.

Testing

  1. Unit test GetOrderTokensCommandHandlerTests.Handle_PaymentMethodNameInTheCustomerLanguage.
  2. With two languages that translate Payments.CashOnDelivery.FriendlyName differently, place an order with Cash on delivery in language B.
  3. Switch the admin to language A and change the order status so an e-mail with {{Order.PaymentMethod}} is queued. The queued e-mail shows the name in language B.
  4. Print the order's PDF invoice from the admin in language A. The payment method is in language B, like the rest of the invoice.

…nd PDF

IPaymentProvider gets GetFriendlyName(languageId), defaulting to FriendlyName so
external plugins keep working; the shipped payment plugins translate it into the
given language. The {{Order.PaymentMethod}} token and the PDF invoice pass
Order.CustomerLanguageId instead of following the request language. Tax and
shipping provider errors are logged with SystemName.
Copilot AI balanced review requested due to automatic review settings October 18, 2026 06:06

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

Order e-mails and PDFs now get the payment method name through
GetPaymentMethodName(order): the name in the order's language, the
friendly name when the order has no language or no translation, and the
system name when the provider is missing or gives no name. An order
without a language no longer throws, a missing translation no longer
shows the resource key, and the Vendor order PDF uses the same name.
Comment thread src/Tests/Grand.Business.Checkout.Tests/Extensions/PaymentExtensionsTests.cs Dismissed
@KrzysztofPajak
KrzysztofPajak merged commit 2f88bc8 into develop Oct 18, 2026
9 checks passed
@KrzysztofPajak
KrzysztofPajak deleted the refactor/business-explicity-pr6b branch October 18, 2026 07:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants