A RefundDestinationStrategy defines a possible destination for a refund. The default destination is the original payment method, but plugins can add additional destinations such as store credit, gift cards, or vouchers.
When a non-default destination is selected, this strategy's createRefund() method
is called instead of the PaymentMethodHandler.createRefund(). If your destination
shares logic with an existing payment method handler (e.g. both a store-credit payment
handler and a store-credit refund destination need to call the same API), extract the
shared logic into a service and inject it into both.
A refund to a non-default destination still draws its balance from a Payment on the Order, which is what limits the amount that can be refunded. The Payment identifies where the money came from; the destination identifies where it goes.
Example
Register in VendureConfig:
InjectableStrategystringA unique code identifying this refund destination. The code default is reserved for the
built-in destination which refunds to the original payment method.
LocalizedStringArrayA human-readable description of this destination, used in the admin UI.
(ctx: RequestContext, order: Order, payment: Payment) => boolean | Promise<boolean>Whether this destination is available for the given Order and Payment. Availability is determined per-Payment, since a destination may be valid for one of an Order's payments but not another.
This is called when resolving the refundDestinations query to build the list of Payments
a destination may be used with, and again when a refund is created, to verify that the
Payment chosen by the administrator is one of them.
In both cases the Order has its payments relation loaded, and each Payment has its
refunds loaded. No other relations are loaded; use the EntityHydrator if the
strategy needs more, such as order.customer or order.lines.
(ctx: RequestContext, input: RefundOrderInput, amount: number, order: Order, payment: Payment, args?: JsonCompatible<any>) => CreateRefundResult | Promise<CreateRefundResult>Execute the refund to this destination. Called instead of
PaymentMethodHandler.createRefund() when this destination is selected.
The returned CreateRefundResult determines the refund state
and any associated transaction ID or metadata. If this method throws when earlier targets of
the same refund have already been processed, their Refunds are kept and the mutation returns
a RefundIncompleteError. If it throws for the first target, the error propagates and no
Refund is created.
The order and payment are hydrated in the same way as for isAvailable().
Architecture reviews, custom plugin work, migrations, ongoing support. Get a hand from the team that builds Vendure.
Talk to the team