Make

What it is and why

Make (formerly Integromat) is a visual scenario builder where modules are joined by "pipes" and you can see the data flowing from step to step. It shines at complex logic: routers (branching), iterators/aggregators (loops over arrays), filters on every connection. Take it when you need automation more powerful than a simple "if → then" like Zapier, but without running your own server like n8n. It is a great fit for "payment received → a chain of actions with branches".

How to do it (step by step)

1. Sign up at make.com — there is a free plan (a monthly operations limit). Billing is in foreign currency, so in Russia you need a non-Russian card.
2. Create a Scenario. On the canvas click "+" → pick the first module = the trigger (Watch for new records, Webhook, schedule).
3. Webhook. The Webhooks → Custom webhook module gives you a URL → paste it into your payment provider or form. Make listens on that address.
4. Keep adding modules in a circle: each next one is dragged out of the previous. Data mapping is done by dragging fields from the dropdown panel (you can see the input structure).
5. Router. For branching, add a Router → attach a filter (condition) to each branch. For example, a "payment succeeded" branch and an "error" branch.
6. Iterator/Aggregator. If the input is an array (a list of products), the Iterator splits it into items and the Aggregator puts it back together.
7. Error handling. Right-click a module → Add error handler (retry/ignore/notify) so the scenario does not fail silently.
8. Schedule and run. Set the polling interval or "on webhook", then switch it ON. The History tab holds logs of every run, operation by operation.

A ready-made recipe/combo

"Payment with branching → delivery → CRM": a webhook from the payment provider → Router: branch A (status "paid") → an access-granting module (Telegram/email) + a row in Google Sheets + a new deal in amoCRM; branch B (status "error/refund") → a notification to the manager in Slack/Telegram. Every connection has a filter by amount or product. Make shows you clearly in History which branch each payment took.

What it costs (honestly)

The logic: billing by operations (each module action = one operation). The free plan has a small monthly operations limit. Paid plans give you a package of operations per month plus a shorter polling interval. The bigger the volume, the more expensive it gets (the main downside versus self-hosted n8n). Billing is in foreign currency. Exact amounts are on Make's site and they change.

When it fits / when it doesn't

• Fits: you need complex logic (routers/loops/filters) without your own server; you value visual clarity; volumes are moderate; you have a foreign-currency card.
• Doesn't fit: very high operation volumes (expensive — take self-hosted n8n); you need Russian billing in rubles (Albato); you need maximum simplicity for a beginner (Zapier).

Risks and responsibility

Payment scenarios touch buyers' personal data (152-FZ: consent) and run through a foreign cloud service — assess the cross-border data transfer. Money/receipts — fiscalization under 54-FZ is on the payment provider's side. Automated mailings require consent (152-FZ). Keep API keys in Connections, not in plain fields. See the section disclaimer.

🤖 Prompt helper

You are a Make.com expert. Design a scenario for: "{the task in plain words, which services}". Give me: (1) the sequence of modules; (2) where to put a Router and which filters go on the branches; (3) whether an Iterator/Aggregator is needed and where; (4) how to set up an error handler; (5) roughly how many operations one run will eat (to estimate the plan). Step by step, what to click and where.