Model a Payment Failure Path in BPMN (Retry, Then Cancel)
Happy paths are easy; failures are where requirements hide. Model what happens when an online shop payment fails: a timer event for the wait, a retry, and an error end event for the cancelled order, then export the model as SVG from the free bpmn.io modeler.
Step by step
Unhappy paths
- Payment failure. When a payment fails, the process model should say what happens next. If it doesn't, nobody builds it. Here a failure path is added to an online shop's order process.
- New diagram. Open a new diagram in bpmn.io and name the start event Payment submitted.
- Happy path. From the start event's menu, add a task named Charge card. Next, add a gateway that asks Payment OK? If yes, the order is confirmed: add a Confirm order task and label its arrow Yes. End the happy path with an end event named Order confirmed.
Timer event
- Wait. If no, the process waits before trying again. From the gateway's menu, drag the double circle (an intermediate event) below it, name it Wait one day and label its arrow No. Click the wrench, type timer and pick Timer intermediate catch event. The clock icon means the process pauses here until the time is up.
Retry
- Retry. After the wait, drag a task from the timer's menu to the space below it and name it Retry payment. Then add a second gateway that asks Paid now?, placed right under Confirm order. If yes, the order rejoins the happy path. Drag the arrow tool from this gateway onto Confirm order and label it Yes.
Error end
- Cancel. If no, the order is cancelled. Add an end event named Order cancelled and label its arrow No. Use the wrench to make it an Error end event. The lightning bolt shows this ending is a failure, not a normal finish.
Export
- Export. To put the model in a requirements document, click the SVG button at the bottom left. It downloads a picture of the diagram.
- The finished model. Click on empty space to see the whole model: the happy path on top, the failure path below, and every path has an end.
Recap
- The rules. Model the failure, not just the happy path. Use a timer event for the wait, loop back with a labelled arrow, and end a failure with an error end event.
Common mistakes
- Modelling the wait as a task. A task means someone does work, so a Wait one day task is misleading. Use a timer intermediate catch event, which shows the process is paused until the time is up.
- Ending the cancelled order with a plain end event. A plain end event looks like a normal finish. Change it with the wrench to an Error end event so the lightning bolt marks it as a failure.
- A retry loop with no way out. If every failed retry loops back to the wait, the process never ends. Add a second gateway, like Paid now?, and send its No to an end event.
- Unlabelled gateway arrows. Without Yes and No on the arrows out of Payment OK? and Paid now?, readers can't tell which path is which. Label every arrow leaving a gateway.
When a business analyst uses this
In a workshop with the payments team, walk through the failure path. Each shape raises a requirement to agree on: how long the wait is, how many retries are allowed and what the customer is told when the order is cancelled. Then export the SVG into the requirements document for sign-off.
Questions people ask
How do I export a BPMN diagram as SVG in bpmn.io?
Click the SVG button at the bottom left of the modeler. It downloads a picture of the diagram that you can put in a requirements document.
What is a timer intermediate catch event in BPMN?
It is a double circle with a clock inside. The process pauses there until the set time is up, such as waiting a day before retrying a payment.
What does an error end event mean in BPMN?
It is an end event with a lightning bolt inside. It shows the process ended in failure, like a cancelled order, rather than finishing normally.
