Three PayPal triggers start a run the moment PayPal reports an event:
| Trigger | What it says | PayPal event |
|---|---|---|
| Payment captured | When a payment is captured | PAYMENT.CAPTURE.COMPLETED |
| Invoice paid | When a PayPal invoice is paid | INVOICING.INVOICE.PAID |
| Refund completed | When a refund is completed | PAYMENT.CAPTURE.REFUNDED |
They are instant triggers, and Bizomate sets them up in PayPal when you publish — see How instant triggers work. You paste nothing.
Who can do this
Workspace Admins and Editors, on every plan. Viewers see the trigger and its status but cannot change it.
Before you start
A PayPal connection — see Connect PayPal.
Steps
Open the workflow in the designer and open the trigger picker — Browse all triggers on an empty workflow, or select the trigger and Change how it starts.
Under PayPal, select the trigger — for example Payment captured. It reads PayPal · instant.
In Connection, choose your PayPal connection. The panel says Publishing sets this up in PayPal, and every publish sets it up again. It stays while the workflow is published — switched off, what arrives is ignored — and is taken away when the workflow is deleted or starts another way.
Add the steps, then Publish.
Publishing adds a webhook for the trigger's event to the connection's REST app in PayPal — in Sandbox or Live, as the connection is. The panel reads Waiting for the first event.
Make the event happen — for a Sandbox connection, pay an order or invoice with one of PayPal's sandbox buyer accounts.
Within seconds the panel reads Listening — instant — Last event 10:45 · Payment captured · $ 49.00.
On Output, select Use the last event, then Test run.
What the trigger gives
Each event is one item:
| Field | What it is |
|---|---|
event |
The PayPal event — PAYMENT.CAPTURE.COMPLETED. |
id |
For Payment captured, the capture's id — use it in Refund a capture. For Refund completed, the refund's id. |
status |
COMPLETED … |
invoiceNumber |
For Invoice paid, the invoice's number. |
amount, amountCurrency, amountText |
49.00, USD, $ 49.00. |
What happens next
- Each event starts one run of the live version, in Production, named after it — Payment captured · $ 49.00.
- Every event is checked with PayPal. For each delivery, Bizomate asks PayPal to verify its signature against the webhook it made. One PayPal does not verify is answered 401 and starts nothing.
- Every publish sets the webhook up again: Bizomate deletes the one it made before and adds a new one.
- Changing to another kind of trigger and publishing, or deleting the workflow, deletes the webhook from PayPal.
Good to know
- One workflow, one webhook. Each workflow with a PayPal trigger adds its own webhook to the app. PayPal limits how many webhooks one app can have.
- Test with real sandbox payments, not PayPal's webhook simulator: PayPal cannot verify a simulated event, so Bizomate refuses it.
- Switching off does not delete the webhook. Events still arrive and show as the last event, but start no runs.
If something goes wrong
| What you see | Why | What to do |
|---|---|---|
| Not listening — PayPal would not take Bizomate's address: PayPal refused: … Fix it, then publish again. | PayPal would not add the webhook, in its own words — most often the app already has as many webhooks as PayPal allows, or the secret was changed. | Delete webhooks the app no longer needs in PayPal, or Reconnect, then publish again. |
| Not listening — … No connection is chosen for this step. … | Connection is empty. | Choose one, then publish. |
| Waiting for the first event stays | The event happened in the other environment, or came from the simulator. | Make a real payment in the connection's environment. |
| Nothing has arrived yet — make one happen in PayPal, then try again. on Output | No event has arrived. | Make one, wait for Listening — instant, then Use the last event. |