Some payment steps take a customer's money or send money back — a capture or a refund. Bizomate marks them Moves money, shows whether their connection holds a live key or a test key, and gives each one an idempotency key so that a step that runs again pays once. This article explains each of these, and how to type amounts for every payment step.
Who can do this
Workspace Admins and Editors add and change payment steps, on every plan — Razorpay, Stripe, Cashfree and PayPal are not premium connections. Viewers see the tags, the notes and the settings, but cannot change them or start a test run.
Which steps move money
| Service | Steps marked Moves money |
|---|---|
| Razorpay | Capture a payment, Refund a payment |
| Stripe | Create a refund |
| Cashfree | Refund an order |
| PayPal | Capture an order, Refund a capture |
Other payment steps — payment links, orders, invoices, customers, lookups — ask for money or read it, but move none themselves.
How you can tell
- In the step picker and on the canvas, the step carries a Moves money tag.
- At the top of the step's settings, a note says what it does: This step sends money out of your account. for a refund, or This step takes the customer's money. for a capture.
- Under Connection, once a connection is chosen:
- Live key — real money., in red, when the connection holds a live key.
- The Test mode pill and Test key — no real money moves. when it holds a test key.
- Every other step on a test-mode connection shows the Test mode pill and This connection holds a test key. The pill is on the step's card too, and beside the connection on Connections.
Bizomate reads test mode from the key itself or from the connection's Environment:
| Service | Test mode when |
|---|---|
| Razorpay | The Key ID starts rzp_test_. |
| Stripe | The Secret key starts sk_test_ or rk_test_. |
| Cashfree | Environment is Sandbox (test). |
| PayPal | Environment is Sandbox (test). |
Steps
Set up a step that moves money:
- Add the step — for example Razorpay · Refund a payment. The settings open with Moves money and the note.
- In Connection, choose the connection. Read the line under it: Live key — real money. or Test mode — Test key — no real money moves.
- Fill in the payment, and the amount if there is one — see Amounts below.
- Leave Idempotency key as
{{ run.id }}unless you have a reason to change it — see Why a retried step pays once below. (Razorpay's Capture a payment has no idempotency key: it looks at the payment first, and one already captured is given back, not captured again.)
Test the workflow:
Select Test run.
- With a test key, the run starts straight away. The service takes or refunds test money only.
- With a live key, Bizomate asks first. The dialog Test run says, for example, This workflow refunds ₹ 1,499.00 with a live Razorpay key. A test run pays for real.
Choose:
- Cancel — nothing runs. Change the step to a test-mode connection to test without real money.
- The red button, which says what it does — Refund ₹ 1,499.00, or Refund for real when the amount comes from an earlier step and nobody can know it before the run. A full refund reads This workflow refunds a payment in full with a live Razorpay key. A test run pays for real.
The button reads Starting, then the test run starts and really moves the money.
Publish:
- Select Publish.
- If any step — a trigger included — uses a test-mode connection, Bizomate asks Publish with test keys? — One step uses a test-mode connection. Customers will not be charged by it. (or 3 steps use test-mode connections. Customers will not be charged by them.).
- Choose:
- Choose live connections — the dialog closes and nothing is published. Change each step's Connection to one with a live key, then publish again.
- Publish anyway — it publishes with the test keys. Use this while you are still trying the workflow out.
Why a retried step pays once
Each step that moves money (and PayPal's Create an order, which makes an order for the customer to approve — it moves no money itself, so it has no tag, but its key stops a retry making two orders) sends the service an idempotency key — A retry of this step sends the same key, so the service pays once. Run again, Test run and Run this step start a new run with a new key, and pay again. Bizomate adds the step's id, and the item's position, to it.
- It defaults to
{{ run.id }}— the run's own id. Bizomate puts the step's own id after it, so two money steps in one workflow never share a key, and then the item's position, so the items of one run never share a key either. A key longer than 40 characters is shortened to 40. - Within one run, the key stays the same. If the step is set to try again when it fails — see Make a step try again when it fails — and the first try reached the service before failing, the next try sends the same key, and the service gives back what it already did instead of paying again.
- How each service keeps its word:
| Service | How the key is used | A repeat gives back |
|---|---|---|
| Razorpay | As the refund's receipt. Before refunding, Bizomate looks for a refund on that payment with the same receipt. | The earlier refund, with alreadyRefunded set to true. |
| Stripe | As Stripe's own Idempotency-Key. |
Stripe's answer to the first request. |
| Cashfree | As the refund's own refund id. Before refunding, Bizomate looks for that refund on the order. | The earlier refund, with alreadyRefunded set to true. |
| PayPal | As PayPal-Request-Id, on Create an order, Capture an order and Refund a capture. |
PayPal's answer to the first request. |
- A new run is a new key, and pays again. Run again on a run's page, every Test run, and Run this step each start a new run, so the step refunds or captures again. That is what they are for — check before you use them on a run whose money step succeeded. See Run a workflow again from a past run.
- A key of your own. To make a refund happen once whatever run makes it — for example once per order — set Idempotency key to a value that names the order, such as
{{ $json.orderId }}. Bizomate still adds the step's id. A key that reads the item — with$jsonorsteps.— is already its own for each item, so Bizomate adds no position to it, and the same order keeps the same key in whichever run it comes again.
Amounts
Type amounts the way people write them, in the currency's main unit — rupees, dollars, euros. Bizomate converts them for the service.
- Accepted: 1499, 1499.00, 1,499.00, ₹ 1499. Bizomate keeps the digits and the decimal point and ignores the rest.
- Razorpay and Stripe take amounts in the smallest unit, so Bizomate sends paise — 1499.00 goes as 149900. Cashfree and PayPal take the main unit, and get 1499.00.
- Decimal places follow the currency: two for rupees, dollars, euros and pounds.
- Values from earlier steps work too:
{{ trigger.amountMain }}.
What comes back:
| Field | Razorpay and Stripe | Cashfree | PayPal |
|---|---|---|---|
amount |
As the service has it, in the smallest unit — 149900. | In rupees — 1499. | In the main unit, as text — 1499.00. |
amountMain |
In the main unit — 1499. | — | — |
amountCurrency |
— | — | The currency — USD. |
amountText |
Ready to show — ₹ 1,499.00. | ₹ 1,499.00 | $ 1,499.00 |
To put an amount in a message, use amountText; to pass it to another payment step, use amountMain (or amount from Cashfree and PayPal).
Good to know
- Test keys never move real money. Use a test-mode connection for building and testing, and a live one when the workflow goes to work. With a connection variable, each environment can use its own — see Variables and environments.
- The test run question appears once, for the first money step on a live key, even if the workflow has several.
- Run this step asks first too. On a money step with a live key, the dialog Run this step says, for example, This step refunds ₹ 1,499.00 with a live Razorpay key. Running it pays for real. The red button runs it; Cancel runs nothing. It is a new run with a new key, so it pays again. See Run one step on its own.
- A step runs once per item. If three payments reach a refund step, it makes three refunds, and each item sends its own key — the run's key with the item's position after it. A retry of the step sends each item the key it had before, so the items that already went through are not paid twice.
If something goes wrong
| What you see | Why | What to do |
|---|---|---|
| Amount “abc” is not an amount — write it in rupees, like 1499.00. | The amount has no number in it, or a value from an earlier step was empty or text. | Type a number, or check the value it reads. |
| Amount must be more than zero. | The amount is 0 or less. | Give an amount above zero. |
| Amount 1499.505 has more decimal places than INR has. | More decimals than the currency has. | Round it to two places. |
| Amount is empty when the step ran — … | A part refund, or a step that needs an amount, got none. | Fill in Amount, or check the value it reads. |
A refund shows alreadyRefunded: true |
The same key was used before — the step ran again within one run, or your own key repeats. | Nothing, if that was a retry. If you meant a second refund, use a different key. |
| Publish with test keys? when you meant to go live | A step, or the trigger, still uses a test-mode connection. | Choose live connections, change each Connection, then publish. |