Invoice number on the bank statement

obey24com commented 2 years ago

Description

Hi folks, to be able to identify a bank transaction to a Woocommerce order, it should be possible to display an invoice number (and possibly also a customer number) on the customer's bank statement.

There is no other way to identify a transaction that the customer sees on his bank statement with an order from Woocommerce.

Design

This options can be displayed as shortcodes (or variables etc.) under WooCommerce > Settings > Woocommerce Payments > "Transaction Preferences"

Dev notes | Bank Statement

Since the characters are limited to 22, the variables/shortcodes should be very short or shouldn't even count

jbordonado commented 2 years ago

This is the Stripe doc about statement descriptors: https://stripe.com/docs/statement-descriptors

What I take from it:

for card charges, it is possible to use a concatenation of a static statement and a dynamic statement. The dynamic statement can be passed as statement_descriptor_suffix in the intent creation request and will be automatically concatenated with the statement description saved in the account (which corresponds to the one defined under Payments > Settings > Transaction Preferences section).
for other charges, we cannot use statement_descriptor_suffix for the dynamic part (not supported) so we'd have to pass statement_descriptor as the complete description already (see here). So Stripe would just look at this field and not use at all what is saved in the account (aka the statement descriptor defined under Payments > Settings > Transaction Preferences section)

In any case, the final statement descriptor is a maximum of 22 characters as mentioned in the description of the issue and as already shown in the WooCommerce Payments settings. This is a limitation that is problematic to having a meaningful dynamic part in my opinion. Just adding the order number like "Woo#XX" is already taking a few characters (and the order number could be 3 or 4 digits at least).

Also, I'm not sure what we can and cannot/shouldn't show on a statement descriptor, from a legal standpoint?

@Automattic/transact-architecture Any thoughts on this?

achyuthajoy commented 2 years ago

Asked for update here - p1657623043816659-slack-C0208C3BXHP

achyuthajoy commented 2 years ago

This PR (in progress) aims to add a shortened statement descriptor to WCPay Settings which would also include an order number while processing the payment.

zmaglica commented 1 year ago

Based on the feedback provided in the issue itself and from the comments, I think that we can move this issue from the Engineering review queue, as the part of the Gamma backlog porter duty to reduce the number of the issues in the Engineering review column.

cesarcosta99 commented 3 months ago

This is long overdue, but I wanted to provide an update regarding this issue. Initially, our proposed approach in #3643 involved:

Adding a "Shortened customer bank statement" setting that can be enabled/disabled. The purpose of this value is to be used as a statement descriptor for card and express checkout transactions.
Making sure the "Full bank statement" and "Shortened customer bank statement" values are being passed correctly to the payment intent during the payment processing. This must take into consideration, among other things, all payment processing variations like UPE vs non-UPE, Blocks vs shortcode, card vs non-card vs express checkout as well as other variations that I may be missing.

However, since the creation of that pull request, Fractal’s focus areas have shifted significantly. Due to these changes, we no longer have the capacity to complete this work.

For the team focusing on the account lifecycle area or anyone interested in taking over, the next steps would involve:

Looping in the design team to review the current design and copies as they're quite old.
Resolving the conflicts in the branch.
Revisiting the 'statement descriptor prefix' approach to consider applying the setting at the Stripe account level.
Following-up with Stripe about potential issues, if any, caused by the refactoring in the approach described in the previous item.

The aforementioned steps are better contextualized here and are crucial to achieving the original goals of the pull request. Alternatively, a new PR can be created from scratch.

Given our current priorities, it wouldn’t make sense for us to continue with this effort at this point. I will be closing that pull request, but I’m more than happy to assist anyone who wants to take over or has questions about the proposed approach.

anu-rock commented 2 months ago

This issue is about improvements to transactions. Sending it to @Automattic/gamma (ping @deepakpathania) as per our product responsibilities Pc2DNy-3z-p2.

zmaglica commented 1 month ago

This is long overdue, but I wanted to provide an update regarding this issue. Initially, our proposed approach in #3643 involved:

Adding a "Shortened customer bank statement" setting that can be enabled/disabled. The purpose of this value is to be used as a statement descriptor for card and express checkout transactions.

Making sure the "Full bank statement" and "Shortened customer bank statement" values are being passed correctly to the payment intent during the payment processing. This must take into consideration, among other things, all payment processing variations like UPE vs non-UPE, Blocks vs shortcode, card vs non-card vs express checkout as well as other variations that I may be missing.

However, since the creation of that pull request, Fractal’s focus areas have shifted significantly. Due to these changes, we no longer have the capacity to complete this work.

For the team focusing on the account lifecycle area or anyone interested in taking over, the next steps would involve:

Looping in the design team to review the current design and copies as they're quite old.

Resolving the conflicts in the branch.

Revisiting the 'statement descriptor prefix' approach to consider applying the setting at the Stripe account level.

Following-up with Stripe about potential issues, if any, caused by the refactoring in the approach described in the previous item.

The aforementioned steps are better contextualized here and are crucial to achieving the original goals of the pull request. Alternatively, a new PR can be created from scratch.

Given our current priorities, it wouldn’t make sense for us to continue with this effort at this point. I will be closing that pull request, but I’m more than happy to assist anyone who wants to take over or has questions about the proposed approach.

@rogermattic could you please review the proposed design and copies as @cesarcosta99 suggested before we proceed with the coding part?

Automattic / woocommerce-payments