There are two ways to get events to your handler: send a test event from the dashboard, or make a real event happen in sandbox. Both arrive the same way they will in production.
Send a test event
In the dashboard, open Developers, then Events, and choose Send test event. Pick an event from the Event catalog and send it.
It is a real delivery. The event goes to the URL subscribed to it, signed with that URL’s secret, on the same retry schedule as any other event. The attempt appears in the Events list with its response code, and you can replay it.
It is marked. data.test is true on every test event. Check it before your handler acts on anything.
Nothing behind it exists. The payload has the shape of the real event. No record is created and no money moves, so its ids return nothing when you read them. For an rfi.* event you can pick one of your own requests for information, and the payload is built from it.
It needs a subscribed URL. A test event goes only where a real one would. If no active URL subscribes to the event, it goes nowhere. The dialog tells you before you send.
The button also works in production, where it reaches your production URL. It needs a role that manages webhooks — see Roles and permissions.
Make an event happen
The sandbox produces real events from real actions, so the way to test a handler is to drive the lifecycle that emits what you want to receive.
Your first complete payment in sandbox walks the whole sequence, and every step of it emits.
Reaching your handler while you develop
Your endpoint has to be reachable from the internet, which a service on your laptop is not. A tunnel that exposes a local port over a public HTTPS URL is the usual way through; register the tunnel’s URL as your sandbox endpoint.
A tunnel URL usually changes each time you restart it, and re-pointing your endpoint every morning is a chore even though you can do it yourself in the dashboard. Use a tunnel that gives you a stable address.
What to check while testing
That you answer in time. Log how long your handler takes end to end, not just how long your business logic takes. The budget is 30 seconds.
That you verify the signature. Point something else at your endpoint and confirm it is rejected — a handler that never rejects anything has not been tested. See Validate signatures.
That a repeat is harmless. Send the same event to your handler twice and confirm the second one changes nothing. This is the property most worth proving before production.
That an unknown event does not break you. Events are added over time. A handler that throws on a name it does not recognise will start failing on a day nobody deployed anything. 
