Open obey24com opened 2 years ago
This is the Stripe doc about statement descriptors: https://stripe.com/docs/statement-descriptors
What I take from it:
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).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?
Asked for update here - p1657623043816659-slack-C0208C3BXHP
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.
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.
This is long overdue, but I wanted to provide an update regarding this issue. Initially, our proposed approach in #3643 involved:
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:
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.
This issue is about improvements to transactions. Sending it to @Automattic/gamma (ping @deepakpathania) as per our product responsibilities Pc2DNy-3z-p2.
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?
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