killbill
Add support for voiding a Capture or Credit
Some gateways (e.g. CyberSource) support voiding captures and credits. From the documentation:
A void cancels a capture or credit request that you submitted to CyberSource. A transaction can be voided only when CyberSource has not already submitted the capture or credit request to your processor. CyberSource usually submits capture and credit requests to your processor once a day, so your window for successfully voiding a capture or credit request is small. CyberSource declines your void request when the capture or credit request has already been sent to the processor. You cannot perform a follow-on credit for a transaction that has been voided. You cannot undo a void.
When you void a capture, a hold remains on the unused credit card funds. If you are not going to re-capture the authorization as described in "Capture After Void," page 71, and if your processor supports authorization reversal after void as described in "Authorization Reversal After Void," page 39, CyberSource recommends that you request an authorization reversal to release the hold on the unused credit card funds.
If your processor supports multiple captures, you can capture an authorization after you void previous captures associated with the authorization.
While we cannot know in Kaui the capabilities of the plugin (yet -- see proposal for per-plugin state machines), we should relax the current constraints in the UI and add links to void specific transactions.
For the plugin to find the original transaction reference, we can pass the linked_transaction_type plugin property.
Note that we now support per-plugin payment state machines, so the UI could be driven by the specific configuration of the plugin associated with the payment.
While it's now easy to get access to the plugin state machine, we only have access to the raw XML in Kaui. We would need a lot of logic on the client side to understand allowed transitions (we don't even have access to the current payment state name).
It would be better instead to have a new API server-side which would return the list of available operations for a given payment.