Invoice number on the bank statement

[obey24com]

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]

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]

Asked for update here - p1657623043816659-slack-C0208C3BXHP

[achyuthajoy]

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]

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]

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

1. 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.
2. 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:

1. Looping in the design team to review the current design and copies as they're quite old.
2. Resolving the conflicts in the branch.
3. Revisiting the 'statement descriptor prefix' approach to consider applying the setting at the Stripe account level.
4. 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]

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

[zmaglica]

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

1. 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.
2. 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:

1. Looping in the design team to review the current design and copies as they're quite old.
2. Resolving the conflicts in the branch.
3. Revisiting the 'statement descriptor prefix' approach to consider applying the setting at the Stripe account level.
4. 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?

[rogermattic]

Sorry for the late response!

I love the stuff that's being discussed here! Just so I double-check has anything been done regarding the improvements on this in the meantime (since Aug 7)?

to review the current design and copies as they're quite old

Also, just checking – we're obviously talking here about reviewing and additions/modifications to this section in Settings, right?

Some things I also wanted to confirm from your perspective:

1. Do I understand correctly this is about the Customer bank statements?
2. Will the current limit (22 chars) be considered as the shortened bank statement?
3. What's the limit for the full bank statement?
4. Do we want to always include the order number? or
5. Do we want to give the users the choice of what they want to include (i.e. custom part, order number,customer number?
6. Can the user decide?
7. Do we want to give the user a chance to include a custom descriptor as well as is now?

Sorry for all these questions, but it will help immensely if you could provide a little bit more info on this :) Thanks!
CC: @zmaglica @cesarcosta99

[cesarcosta99]

Also, just checking – we're obviously talking here about reviewing and additions/modifications to this section in Settings, right?

That's right, @rogermattic! More specifically about the Customer statements sub-section 🙂

1. Do I understand correctly this is about the Customer bank statements?

Yes, that's correct.

2. Will the current limit (22 chars) be considered as the shortened bank statement?
3. What's the limit for the full bank statement?

No, the current limit is considered as the "full bank statement". It must contain between 5 and 22 characters. 22 characters is the limit for the shortened statement too, however, it's split between prefix and suffix and we must respect that 22 characters limit when concatenating both.

4. Do we want to always include the order number? or
5. Do we want to give the users the choice of what they want to include (i.e. custom part, order number,customer number?
6. Can the user decide?
7. Do we want to give the user a chance to include a custom descriptor as well as is now?

The idea back then was to have the shortened statement for card transactions and the full statement for all the other non-card transactions. The full statement is something that the user decides on. On the other hand, the shortened statement was composed by a prefix, which the user decided on, and a suffix, which was something we decided on. So, in an "ideal" scenario for the shortened statement we would have the merchant setting the store name and us setting the order number dynamically, which would be concatenated to something like Foo Store* #123. I think we decided on the order number for the suffix because it'd be something the user could identify in the store AND in their card statement.

It's been a long time since I touched this and I got some answers on https://docs.stripe.com/get-started/account/statement-descriptors, that's the best place to understand how all of these rules apply. I noticed they did some slight changes but I think the idea remains the same. It looks like @Automattic/gamma is picking this up and they should be able to follow-up with you on insights and decisions moving forward 🙂

[rogermattic]

Thanks @cesarcosta99 for your reply, it's very helpful!

CC @ricardo since you worked on this in the #3643.

What do you think about this version, could we display it this way?

I like that you suffixed the name with the order number, not the other way around. Think it works! I just tweaked the layout a bit and the labels.. plus tidied up the spacing etc.

I'm thinking that we could disable the short statement field when the Add order number tick is unchecked.

[ricardo]

What do you think about this version, could we display it this way?

@rogermattic I think it looks great!

Perhaps the order number greyed suffix could be like an input mask that's added after the short statement descriptor.

I'm thinking that we could disable the short statement field when the Add order number tick is unchecked.

I agree. And make it required if the checkbox is ticked.

[rogermattic]

Thanks @ricardo !

Perhaps the order number greyed suffix could be like an input mask that's added after the short statement descriptor.

Absolutely! I’ll create a flow mockup for this so it’s clearer than just a static image. 😊

BTW, I’ll be publishing a P2 soon with a few suggested improvements for Settings, and this will be one of them. Do you think we should create a new issue in GH for this, or just post the final designs in one of the two existing issues?

[ricardo]

Do you think we should create a new issue in GH for this, or just post the final designs in one of the two existing issues?

@rogermattic If the suggested improvements are outside the scope of the existing issues, I think we should create a new one.

[rogermattic]

@ricardo I created this new issue for it! Does that work?

[ricardo]

@rogermattic Looks good to me 👍.