Commands and Events

The Refund Plugin uses a decoupled pipeline so you can swap or extend parts without breaking others. Using RefundUnitsAction as an example, the sequence is:

1. Get request data

2. Create a Command and fill it with data

3. Dispatch the Command

4. Handle the Command

5. Fire an Event

6. Catch the Event in a Listener

This command–event structure keeps each step independent and easy to customize.

What happens after a refund (default)

After units are refunded, the plugin triggers a post-refund pipeline that:

• generates a Credit Memo, then

• creates a Refund Payment.

These are strictly coupled: the RefundPayment is created after the CreditMemo; if RefundPayment creation fails, the related CreditMemo is not created. The orchestrator is Sylius\RefundPlugin\ProcessManager\UnitsRefundedProcessManager.

To extend this pipeline, implement UnitsRefundedProcessStepInterface and tag your service; steps run by priority (descending):

<?php
// src/Refund/NotifyAccountingAfterRefund.php
namespace App\Refund;

use Sylius\RefundPlugin\Event\UnitsRefunded;
use Sylius\RefundPlugin\ProcessManager\UnitsRefundedProcessStepInterface;

final class NotifyAccountingAfterRefund implements UnitsRefundedProcessStepInterface
{
    public function __invoke(UnitsRefunded $event): void
    {
        // push credit memo + refund data, emit metrics, etc.
    }
}

# config/services.yaml
services:
  App\Refund\NotifyAccountingAfterRefund:
    tags:
      - { name: 'sylius_refund.units_refunded.process_step', priority: 100 }

Check out ProcessManagers for more info.

Where to hook your logic

Listen to the refund event

Use the event to send emails, or call for online refunds:

Debug tips

• List events:

bin/console debug:event-dispatcher | grep refund

• Check tagged steps:

bin/console debug:container --tag=sylius_refund.units_refunded.process_step