What You Can Build: Make.com + Payment Links
Make.com (formerly Integromat) is a visual automation platform with deep branching, error handling, and routing capabilities — making it well-suited to payment workflows that need conditional logic. Shuttle Links Checkout plugs into Make as a fully featured app, which means any Make trigger can produce a payment link, and any payment outcome can fire a downstream scenario.
Make's strength over simpler workflow tools is its visual scenario builder. You can model conditional payment flows — "if deposit not paid within 24 hours, cancel link and notify sales", "if amount > £5,000, route to a manual approval step before generating the link", "if customer is in a particular country, use the local PSP". These branching scenarios are far easier to express in Make than in linear automation tools.
Like with Zapier, you don't need a developer. The whole setup is no-code, and you can switch the underlying payment gateway without rebuilding the scenario.
Supported Payment Gateways via Make.com
Shuttle abstracts the payment layer, so the same Make.com scenario can run against any of 30+ supported PSPs. The most common gateways used with Make.com today:
- Stripe — global card processing, the most common default
- Adyen — enterprise-grade, multi-region settlement
- Worldpay — UK and European merchants
- Checkout.com — global, popular with high-growth platforms
- Braintree (PayPal) — bundled with PayPal Wallet support
- Mollie — European-first PSP with strong local methods
- Square — small business and US-led merchants
- GoCardless — direct debit and recurring collection
- PayPal, Paysafe, Global Payments, FreedomPay, Authorize.Net, USAePay, Trust Payments — see the full list at our payment providers directory
Switching PSP doesn't require rebuilding the scenario — only the underlying Shuttle gateway configuration changes.
Common Make.com Scenario Templates for Payments
1. PandaDoc / Docusign signed → deposit collected
The classic agency and consulting flow. When a proposal is marked accepted in PandaDoc or Docusign, Make.com generates a payment link for the agreed deposit. If the link isn't paid within 48 hours, a follow-up branch sends a reminder; if still unpaid after 7 days, the link is cancelled and the deal is flagged in the CRM. Use Make's branching to handle the full lifecycle, not just the happy path.
2. WhatsApp Business message → payment link reply
A customer sends a WhatsApp message ("can I pay for the £150 service?"). Make.com picks up the inbound message, generates a Shuttle payment link, and replies with the link in the same WhatsApp conversation. Used by retail, hospitality, and service businesses that already use WhatsApp Business as the primary customer channel.
3. Chatbot accepted offer → payment link
An AI agent or chatbot (Cognigy, Voiceflow, Tidio, ManyChat) negotiates an offer with a customer. When the customer accepts, the bot fires a webhook into Make.com, which generates the payment link with the agreed amount and returns it to the bot for delivery. This is the agentic-commerce pattern — payments triggered by conversational AI.
4. HubSpot deal → custom payment link
When a HubSpot deal moves to a particular stage, Make.com pulls the deal value and customer email, generates a Shuttle payment link with those details, and posts the link back into the deal record (or sends it to the customer via HubSpot's email tool). For HubSpot users this is often a better fit than HubSpot Commerce Hub's built-in payment links — Shuttle supports many more gateways and gives you control over the checkout branding. See our HubSpot payment links guide for details.
5. Google Sheets row → bulk link generation with conditional logic
A row appears in a Google Sheet (customer, amount, country). Make.com routes the row through conditional logic: customers in the EU get a Mollie link, customers in the UK get a Worldpay link, customers elsewhere get a Stripe link. The relevant payment link is generated and either emailed directly or written back into the sheet. Used for batch invoicing and event registrations with multi-PSP setups.
6. Calendly booking + amount > threshold → upfront payment
When a Calendly booking is made, Make.com checks the meeting type. If it's a paid consultation above £200, generate an immediate payment link and email it to the customer with a "pay before the call" message. Below £200, skip the payment step and just confirm the booking. Branching scenarios like this are exactly where Make.com outperforms simpler tools.
7. Payment received → multi-step downstream flow
When a Shuttle payment is captured, Make.com fires a sequence: post to the team Slack channel, create an invoice in Xero or QuickBooks, update the CRM record, add the customer to a Mailchimp list, generate a delivery ticket in your warehouse system. Make's strength is the multi-step orchestration of all these downstream actions in one scenario.
How It Works: Setting Up Your First Make.com Scenario
The setup path is similar to Zapier but uses Make's visual scenario builder:
- Connect Shuttle to Make.com. In the Make app library, search for "Shuttle Links Checkout" and authenticate with your Shuttle API key (available in your dashboard).
- Pick your trigger module. Choose any of Make's 1,800+ supported apps, a webhook, or a scheduled trigger.
- Add a Shuttle "Generate Payment Link" module. Map the trigger's data into the link — amount, currency, description, customer email, metadata.
- Add routing or filtering as needed. Use Make's routers and filters to handle conditional flows (high-value approval, region-based PSP selection, retry logic).
- Add a delivery step. Email, SMS, WhatsApp, Slack, the original app — any of Make's connected apps can deliver the link.
- Optional: a second scenario for the payment outcome. Use the Shuttle "Payment Received" trigger to fan out downstream actions when a payment lands.
Make.com's visual builder makes complex scenarios easier to maintain than chains of Zaps. If you have payment workflows with branching logic, Make is usually the better fit.
Make.com vs Zapier vs Direct API
Both Make.com and Zapier offer the same Shuttle capability set. The choice usually comes down to:
- Pricing model — Make.com charges per "operation" (each module run); Zapier charges per "task". For high-volume workflows, Make is typically cheaper, especially when scenarios involve many internal steps.
- Branching and error handling — Make.com's visual scenario builder handles conditional logic, retries, and error branches more elegantly than Zapier's linear path.
- App ecosystem — Zapier supports more apps (6,000+ vs Make's 1,800+), so for niche tools you may need Zapier; for the common stack (Slack, HubSpot, Google Sheets, WhatsApp, PandaDoc) both cover everything you need.
- Team familiarity — if your team already uses one tool, that's usually the better choice. There's no penalty for picking either.
For workflows with simple linear logic, Zapier is faster to set up. For workflows with branching, conditional routing, or many downstream steps, Make.com pulls ahead. Our payment workflow automation guide walks through the side-by-side comparison in more detail.
For very high volume or product-embedded payments, the direct Shuttle API is the right choice — but most teams find Make.com or Zapier covers 80% of payment workflow needs without writing any code.
Shuttle's Zapier integration covers the same use cases described here, in case Zapier is the better fit for your team.