Add a cancel() method to Gateway Interface / Gateways

[jellingsen]

Description

When creating a Payment Gateway you can capture and refund, and you can authorize. But you can't unauthorize or cancel a payment.

For the payment provider that I currently is creating a Gateway for, un-captured payments will stay for several weeks before they are auto-cancelled.

[lukeholder]

@andris thoughts?

[jaydensmith]

No further update on this?

[lukeholder]

• Should be able to cancel uncaptured payment if gateway supports it.

[sjelfull]

@lukeholder Is this something you are working on, or should I take a stab at at PR?

[sjelfull]

Just following up: Our use case is that all our refunds is cancellations of the payment intent instead of the already supported refund.

This is because payment have to happen on or after delivery, while most support cases happens before, usually because they did not get a delivery.

[lukeholder]

@sjelfull you are welcome to make a pull request.

Since you will need to add a cancel() and supportsCancel()method to the gateway interface this will be a breaking change for gateways that do not inherit from base gateway (if any) so would leave this for at least a point release.

[lukeholder]

Also would need to think about adding something to a transaction to know whether it can still be cancelled (time limits for cancellation by gateway usually) so a canCancel() method to transaction model, and canCancelTransaction() method to the transaction service.

[lukeholder]

@sjelfull Just thinking about the implementation of this.

Instead of changing the current GatewayInterface, we would want to create an additional CancellableGatewayInterface with the following 2 methods:

cancel(Transaction $transaction) : RequestResponseInterface
canCancel(Transaction $transaction) : bool

Then in Commerce 4 we will split out the other optional features of a gateway into their own interfaces. (Like partial refund).

You would still add canCancel() to the transaction model which calls the transaction service's canCancelTransaction(). That latter method would see if the gateway implements the CancellableGateway interface (which saves us having to call a supportsCancel() method, and also calls canCancel(Transaction) to know it cancellation is even possible.

Let me know if you have any questions.

[jmauzyk]

I wanted to voice our support for a Void/Cancel functionality for transactions in Commerce and provide some context for why it would be of value to us.

In our case, we follow a workflow where transactions are not captured until shipment, as we believe this approach best serves our customers. However, this means that authorizations remain active until they expire or are manually voided. When a customer cancels an order, leaving the transaction in its authorized state can cause confusion and frustration, as the held funds are not immediately released.

For example, while Visa typically releases held funds after 7 days, other issuers, like MasterCard, may hold them for up to 30 days. This can lead to unpleasant customer service interactions and erode trust. To avoid these issues, we’ve made it our policy to void authorizations for cancelled orders.

Currently, this requires logging into the payment gateway to manually void the transaction. Not only does this create extra work, but it also results in a discrepancy between the transaction status shown in Commerce and the gateway, as Commerce doesn’t offer a Voided or Cancelled status.

I'd love to know if this functionality is on the roadmap and if there's any way we can support its development.

Thanks!