# No code: Zapier, Make and Cyclr

> This is the no-code way to connect to your merchants' Payment Links accounts: instead of building against the API, you use workflow automation tools to connect

This is the no-code way to [connect to your merchants' Payment Links accounts](/platforms/payment-links/intro/): instead of building against the API, you use workflow automation tools to connect your platform to each merchant's Payment Links account.

## Who this is for

You run a software platform that:
- Needs to collect payments on behalf of merchants
- Has no available engineering capacity
- Wants to validate payment demand before building properly
- Has promised payment features that aren't on the roadmap

## How it works

You'll use Zapier, Make or [Cyclr](https://cyclr.com/integrate/shuttle) as your integration layer. These tools will:
1. Watch for payment triggers in your platform
2. Generate Shuttle payment links automatically
3. Deliver links to customers
4. Handle payment notifications
5. Update your platform when payments complete

## What to expect

### Zapier and Make

- **Merchant onboarding**: one by one - each merchant needs their own workflow
- **Best for**: platforms with fewer than 20 merchants
- **Setup time**: 1-2 hours per merchant
- **Scaling**: gets painful after 20-30 merchants

### Cyclr

- **Merchant onboarding**: template-based - set up once, deploy to many
- **Best for**: platforms planning to grow beyond 20 merchants
- **Setup time**: 1-2 days to start, then minutes per merchant
- **Scaling**: handles hundreds of merchants

Beyond that, or for full control, build against the API: see [Connect to Payment Links accounts](/platforms/payment-links/intro/).

## Setting up your payment flow

### Step 1: Identify your payment triggers

Look at your platform and identify when payments need to happen:
- When an invoice is created?
- When a subscription renewal is due?
- When a booking is confirmed?
- When a service request is submitted?

Your platform needs to send a webhook or have an API endpoint that the workflow tool can monitor.

### Step 2: Configure payment link creation

In your workflow tool, set up an action that:
1. Receives the trigger from your platform
2. Extracts the necessary information (amount, customer details, reference)
3. Uses Shuttle's **Create Payment Link** action to create a payment link
4. Captures the payment link URL that Shuttle returns

The workflow tool handles all the API complexity - you just map fields from your trigger to Shuttle's requirements.

### Step 3: Deliver the payment link

Decide how customers will receive payment links:

**Option A: Workflow tool sends directly**
- Configure email/SMS action in the workflow
- Tool sends payment link to customer
- Simple but less control over branding

**Option B: Send back to your platform**
- Workflow returns payment link URL to your platform
- You attach it to invoices, emails, or customer portals
- More work but maintains your brand experience

### Step 4: Handle payment completion

When a customer pays:
1. Shuttle sends a webhook to your workflow tool
2. Workflow tool processes the payment notification
3. You decide what happens next:
   - Update invoice status in your platform
   - Trigger fulfilment
   - Notify merchant dashboard
   - Send confirmation emails

## Merchant onboarding

Each merchant needs to:
1. Create a Shuttle Payment Links account and connect their payment provider. See [Getting started](/merchants/payment-links/getting-started/).
2. Connect that account to the workflow, through the Shuttle app in Zapier or Make. They add a Shuttle connection, choose live or sandbox, log in to Shuttle and grant access to their account. The connection uses OAuth, so the merchant never shares a password or API key with you.

The workflow can be in your Zapier or Make account, with the merchant connecting their Shuttle account to it, or in the merchant's own.

This is manual and doesn't scale well, but works for getting started.

### With Cyclr

You create a parent account with your workflow templates, then:
1. Create a child account for each merchant.
2. The merchant connects their Shuttle account once, through OAuth.
3. Deploy your payment workflow template to it.

Every merchant gets the same workflow, which scales much better for a platform. See [Multi-tenant iPaaS](/merchants/payment-links/single-use-via-multi-tenant-ipaas/).

## Common implementation patterns

### Invoice payment collection
- **Trigger**: New invoice created in your platform
- **Link delivery**: Attach to invoice email or embed in invoice page
- **Completion**: Mark invoice as paid, update accounting records

### Recurring subscriptions
- **Trigger**: Subscription due date reached
- **Link delivery**: Send renewal notice with payment link
- **Completion**: Extend subscription period, update next billing date

### Service deposits
- **Trigger**: Service booking confirmed
- **Link delivery**: Include in booking confirmation
- **Completion**: Mark deposit received, confirm appointment

## What you need from your platform

### Outbound (to trigger payments)
- Webhook when payment is needed, OR
- API endpoint the workflow tool can poll
- Include: amount, currency, customer email, your reference ID

### Inbound (to receive updates)
- Webhook endpoint to receive payment confirmations, OR
- API endpoint the workflow tool can update
- Ability to match payments using reference IDs

## Limitations to consider

- Customers see Shuttle's payment page, not yours - however these are brandable
- While straightforward, you need to learn the workflow tool or contract someone who knows it
- You're dependent on three services (your platform, workflow tool, Shuttle)

## When to move beyond workflow automation

Consider direct API integration when:
- You're processing more than 100 transactions/day
- Workflow tool costs exceed development costs
- You need custom payment experiences
- Latency becomes an issue
- You have engineering resources available

Until then, workflow automation gets you to market without writing code.