Payment methods are by their nature ephemeral. They can change, expire and disappear.
Commerce currently does not handle ephemeral payment methods gracefully for a multitude of reasons. To address these issues typically the solution is to prevent them from being edited and deleted. This introduces several new issues and is not a good long term solution.
Customers may not want to store their credit card information or need to make a correction during checkout if they enter their payment method details incorrectly. Without permission to edit payment methods they cannot make any corrections during checkout and have to create a new payment method.
Their card will eventually expire and they will need to enter a new one and remove the old entry so they don't have to pick between expired and valid cards during checkout.
The following is a list of some challenges site owners face when dealing with ephemeral payment methods
Commerce Authnet is used as an example
Gateway specific transaction details for payments are missing in the payment UI which are oftentimes necessary for order processing and administration. Some details are available on the payment method however these details can change and they are oftentimes incomplete.
This could be remedied by adding a place to store gateway specific information about transactions (payments)
✨ [Parent] Store more transaction specific information on Payment entities Active
The payment UI on orders allows you to refund or cancel a payment. If the referenced payment method is deleted before it expires then it is not possible to cancel an order and refund the customer from the Drupal UI.
This could be remedied by marking payment methods deleted and hiding them from the UI. They could still be used to issue a refund.
#2898218: Implement soft deletes for payment methods →
Different payment gateways have rules regarding how long you have until you cannot refund a transaction. If the expiration date is reached then a payment method that has been soft-deleted can be automatically purged and the refund button no longer shown.
Currently commerce_authnet does not store the refund expiration date on the payment. Is this what the expires column on the payment entity is intended for?
Payment methods that have expired will not be deleted or hidden and can cause confusion during checkout if the customer attempts to use the expired payment method.
At the very least expired payment methods should not be presented to the customer during checkout
#3080552: Don't show expired payment method as an option when checkout →
Don't show non-reusable methods that have been used already.
We need to be able to configure whether payment methods are always created, never created, or whether the user has a choice.
📌 Add checkout settings for payment method behavior Needs review
Customers can create duplicate payment methods that have the same remoteid.
#3115553: Avoid Duplicating payment methods →
When a gateway is removed the associated payment methods remain
#2898217: Delete payment methods when their payment gateway is deleted →
TODO: More testing and clarification of problem space on expired and duplicate payment methods
Active
3.0
Payment
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
I'm moving this to 3.x because the concept is a breaking change and is more appropriate for a new major version
There are some interesting points here, especially around the payment method being required to perform operations on the payment. Frankly, I never worked with a payment gateway with such a requirement but this is good to know. I read that authnet can be used as an example here?