Resources · Make integration

Payment Rails Make integrationAutomate Payment Rails with Make.

Can Make pay people in Payment Rails for you, without a line of code? The Payment Rails Make integration gives you 13 modules: 2 instant triggers, 9 actions and 2 searches. This guide shows finance and ops teams how to connect the account, build a first scenario and pick the right module.

Try the Payment Rails integration on MakeSee the 13 modules

Verified Trustpilot reviews · AI, automation & growth agency

What you can automate

What can the Payment Rails Make integration automate?

The Payment Rails Make integration links your Payment Rails account to Make, a no-code tool where you build a scenario (the automation itself, a chain of steps) out of modules (one brick each: a trigger, an action or a search). Make then creates, reads, updates and deletes payments and recipients in Payment Rails, with no one copying data by hand.

Payees created from your own lists. A contractor signs up in a form or a spreadsheet, and Create a Recipient adds that person to Payment Rails. Create a Payment can follow in the same scenario, so the payout is ready without retyping a name or an amount.

Status changes that reach the right people. Watch Payment Status Updated fires the moment a payment moves to a new status. Send that signal to your accounting tool, a spreadsheet or a chat channel, and the finance team stops refreshing the dashboard.

Clean records on both sides. When a supplier changes their details in your CRM, Update a Recipient keeps Payment Rails in line. Watch Recipient Updated covers the opposite direction, pushing edits made in Payment Rails back to your other tools.

Know the limits before you start. Make itself says its documentation for Payment Rails is short, because little public information exists about the app, so expect to test each module with real data. For anything the listed modules skip, Make an API Call reaches the rest of the API. If you are still choosing a platform, the n8n vs Make comparison lays out the criteria, and the Make pricing page explains how operations are counted. Teams that want a hand can look at the Make training.

Connect

How do you connect Payment Rails to Make?

  1. 01

    Add a Payment Rails module

    In your scenario, click the +, search for Payment Rails and pick any of its modules. Make then asks for a connection, meaning your Payment Rails account linked to Make once and reused by every module of the app. Click Create a connection.

  2. 02

    Name it and authorize Make

    Give the connection a name you will recognize later, such as the account it belongs to. Then follow what Payment Rails asks for: either you approve Make on a Payment Rails page, or you paste the key your Payment Rails account gives you.

  3. 03

    Save and check the module

    Click Save. The module now shows your connection, and Make can list the Payment Rails objects it is able to read. Every other Payment Rails module in the scenario can reuse the same connection without asking again.

First scenario

Your first scenario: pay a new contractor from your own list

GoalWhen a new contractor appears in another tool, Make creates the recipient in Payment Rails and then prepares their payment.

  1. 01

    Create the scenario

    Open the Scenarios page, create a new scenario and click the +. Pick the app where contractors land first, a form or a spreadsheet, and choose the module that watches new entries.

  2. 02

    Add Create a Recipient

    Click the + on the right of the first module and add Create a Recipient from Payment Rails. Create a connection if Make asks, then map the contractor's details from the previous module into its fields.

  3. 03

    Chain Create a Payment

    Add Create a Payment after it. Map the recipient that the previous module just returned, so the payout lands on the right person, then fill in the payment fields with values from your first app.

  4. 04

    Test with Run once

    Add one test contractor in your source app and click Run once. Each module shows the bundles it received, one bundle per item, so you can check that the recipient and the payment look right in Payment Rails.

  5. 05

    Schedule and switch it on

    Set the schedule on the first module. A new scenario checks every 15 minutes by default, which is also the shortest gap on the Free plan. Then turn the scenario on and let it handle the next contractor.

Triggers

What starts a Payment Rails scenario?

2 modules start a scenario when something happens in Payment Rails. A scheduled trigger is checked by Make on the scenario's schedule; an instant one is called by Payment Rails as soon as it happens.

Payment Rails1Watch Payment Status Updated

Watch Payment Status Updated

Instant trigger

In Make“Triggers when a payment's status is updated.”

Your scenario starts whenever a payment in Payment Rails moves to another status, and it receives that payment as a bundle to pass along. This is the trigger to reach for when someone downstream needs to know where a payout stands.

How it fires
instant, Payment Rails calls Make through a webhook as soon as the status changes, so there is no polling clock to set.
When to use it
to tell your accountant, update a spreadsheet row or post in a finance channel each time a payout changes state.
Watch out
add a filter after the trigger if only some statuses matter, otherwise every change costs an operation.
Payment Rails2Watch Recipient Updated

Watch Recipient Updated

Instant trigger

In Make“Triggers when a recipient is updated.”

Edits to a payee in Payment Rails reach Make right away, with the updated recipient as the bundle. Use it to keep the people you pay identical in every tool, with no reconciliation by hand.

How it fires
instant, Payment Rails notifies Make through a webhook the moment a recipient is updated.
When to use it
when a contractor updates their details in Payment Rails and your CRM or supplier sheet must reflect it.
Watch out
if the same scenario also runs Update a Recipient, it can fire itself again, so keep the two in separate flows or filter out your own edits.
Modules

What can the Payment Rails modules do?

Payment Rails gives you 11 modules. For each one: what it does for you, when to reach for it, and what to watch out for.

Payment Rails1

Create a Payment

Action

In Make“Creates a new payment.”

Turns data from another tool into a payment in Payment Rails, ready for the recipient you point it to. It is the module that removes retyping from payouts.

When to use it
after an invoice is approved in your accounting app, or right after Create a Recipient for a brand new payee.
Watch out
run it on test data first, since a payment created by mistake means cleanup with Delete a Payment.
Payment Rails2

Create a Recipient

Action

In Make“Creates a recipient.”

Adds a new payee to Payment Rails from any source Make can read, so a form entry or a CRM contact becomes someone you can pay.

When to use it
when a freelancer or supplier is onboarded elsewhere and should not be typed in twice.
Watch out
search first with Search Recipients if the person may already exist, or you risk duplicates in your payee list.
Payment Rails3

Delete a Payment

Action

In Make“Deletes a payment by ID.”

Removes one payment from Payment Rails, identified by its ID. You feed it that ID from a trigger, a search or a previous module in the same scenario.

When to use it
when a payment was created by error or an invoice was cancelled in your source tool.
Watch out
nothing brings the payment back, so place a filter before it and test with a payment you can afford to lose.
Payment Rails4

Delete a Recipient

Action

In Make“Deletes a recipient by ID.”

Takes a payee out of Payment Rails by ID, which keeps your recipient list limited to people you still work with.

When to use it
when a contract ends and the supplier is archived in your CRM, so both sides stay in step.
Watch out
the deletion is final; fetch the recipient with Get a Recipient first if you want a copy of the details in a sheet.
Payment Rails5

Get a Payment

Action

In Make“Gets a payment by ID.”

Fetches the full record of one payment when you already hold its ID, so later modules can use every detail Payment Rails stores about it.

When to use it
after a trigger or a row in your sheet gives you a payment ID and you need the rest of the record to write a report or a message.
Watch out
without the ID, use Search Payments instead.
Payment Rails6

Get a Recipient

Action

In Make“Gets a recipient by ID.”

Reads one payee by ID and hands their full profile to the next module, which is handy for personalizing an email or filling a ledger line.

When to use it
when a payment bundle carries a recipient ID and you want the person behind it.
Watch out
each call is one operation, so avoid putting it inside a loop over hundreds of items when a search returns the same data.
Payment Rails7

Make an API Call

Action

In Make“Performs an arbitrary authorized API call.”

Reaches any endpoint of the Payment Rails API with the connection you already set up, so the scenario is not limited to the other modules on this page.

When to use it
when you need something the listed modules do not offer, and you have the Payment Rails API reference at hand.
Watch out
you write the request yourself, and Make's own docs for this app are thin, so test it with Run once before going live.
Payment Rails8

Update a Payment

Action

In Make“Updates a payment.”

Changes an existing payment in Payment Rails, so a correction made in your source tool does not need a second manual edit.

When to use it
when an approved invoice is amended before the payout goes out and the payment in Payment Rails has to follow.
Watch out
the module needs to know which payment to change, so get the ID from a trigger or from Search Payments earlier in the flow.
Payment Rails9

Update a Recipient

Action

In Make“Updates a recipient.”

Pushes new payee details into Payment Rails, keeping the profile there aligned with your CRM or HR tool.

When to use it
when a supplier sends new details and your team records them in another app first.
Watch out
paired with Watch Recipient Updated in the same scenario it can loop, so filter out edits that came from Make itself.
Payment Rails10

Search Payments

Search

In Make“Searches payments by given criteria.”

Finds payments that match the criteria you set and returns zero, one or several bundles, one per payment found.

When to use it
to build a list of payouts for a report, or to find a payment's ID before Update a Payment or Delete a Payment.
Watch out
every result runs the next modules once, so narrow the criteria or add an aggregator if you want a single summary.
Payment Rails11

Search Recipients

Search

In Make“Searches recipients by given criteria.”

Looks up payees by the criteria you give and returns each match as its own bundle, which is the safest way to check before creating someone new.

When to use it
right before Create a Recipient, to skip people already in Payment Rails, or to export your payee list to a sheet.
Watch out
an empty result is normal, so add a filter that handles the zero case.
Need help

Need help automating Payment Rails with Make?

A person reads every message.

FAQ

Payment Rails and Make: common questions

01Is the Payment Rails Make integration free?
Yes, Payment Rails is a standard app in Make, so its modules work on the Free plan. That plan has limits: 2 active scenarios, at least 15 minutes between scheduled runs, 5 minutes of execution per run, files up to 5 MB and 512 MB of data transfer. Each module run on one bundle counts as one operation. Paid plans such as Core, Pro and Teams lower the interval to 1 minute and allow unlimited active scenarios. Your Payment Rails subscription is a separate matter.
02What do you need to connect Payment Rails to Make?
A Payment Rails account and a Make account. Make's documentation for this app lists no specific prerequisite and says public information about Payment Rails is limited. The steps are the usual ones: add a Payment Rails module, click Create a connection, give it a name, approve Make or paste the key your Payment Rails account provides, then click Save. That single connection serves every Payment Rails module in your scenarios.
03Do Payment Rails triggers in Make work in real time?
Yes. Both triggers, Watch Payment Status Updated and Watch Recipient Updated, are instant: Payment Rails calls Make through a webhook as soon as the change happens, instead of Make checking on a clock. The scenario therefore starts right after a payment changes status or a recipient is edited. Scenarios that begin with another app still follow the schedule set on their first module, every 15 minutes by default. Add a filter after the trigger if only some changes matter to you.
04What if the Payment Rails module you need is missing in Make?
Use Make an API Call. It calls any endpoint of the Payment Rails API with the same connection as the other modules, so the 13 modules are not a ceiling. Keep in mind that Make describes its Payment Rails documentation as limited, so the Payment Rails API reference is where the request details come from. Test each call with Run once and read the returned bundle before switching the scenario on.
05Should you use Make or n8n for Payment Rails?
It depends on the tool your team already runs. Make offers 13 ready modules for Payment Rails, with 2 instant triggers and a generic API call for the rest. Many apps also have an n8n node, so check whether one exists for Payment Rails and what it covers before choosing. Compare the modules each side gives you for payments and recipients, then pick the platform where your other automations already live.
Same platform

Other docs you might need on this stack.

Browse all integrations