A client needed to send payment links to customers. Simple enough — except they had a team of employees handling billing, and they didn't want anyone to have direct access to the Stripe dashboard. This is the system we built to solve it.
The problem
The manual process looked like this: a team member would take a customer order, log into Stripe, create a payment link for the right amount, copy it, and email it to the customer. Repeat for every order.
Two issues:
- Security. Giving Stripe dashboard access to every billing team member is a significant risk. Anyone with access can see transaction history, issue refunds, and modify settings.
- Efficiency. The manual process took several minutes per order. Across 100+ orders per month, that's hours of low-value work.
The solution needed to let team members trigger billing without ever seeing the Stripe dashboard.
The architecture
The full pipeline has six steps:
- Step 1 — Form submission. A team member fills a Google Form: customer name, email, service, and amount.
- Step 2 — Sheets trigger. The form response lands in a Google Sheet. Make.com watches the sheet and triggers instantly on a new row.
- Step 3 — Customer check. Make.com calls the Stripe Customers API to search for an existing customer by email. If found, it reuses the existing customer ID. If not, it creates a new customer. This prevents duplicate customer records.
- Step 4 — Create price + payment link. Make.com calls the Stripe Prices API to create a one-off price for the specified amount, then calls the Payment Links API to generate a shareable link tied to that price and customer.
- Step 5 — Stripe sends the email. Stripe natively emails the payment link to the customer. No Gmail integration needed — Stripe handles delivery.
- Step 6 — Status update. Make.com writes the payment link URL and a “Sent” status back to the Google Sheet row. This prevents accidental duplicate sends.
The customer deduplication logic
This step is easy to overlook and worth getting right. Stripe lets you search customers by email:
GET /v1/customers?email=customer@example.com
If the response array is non-empty, extract the first result's id and reuse it. If empty, call POST /v1/customers to create a new record.
In Make.com, this is a Router module with two paths — one for existing customers, one for new ones — both converging on the same price creation step. Keeps your Stripe customer list clean and makes transaction history per customer useful.
Why Stripe Payment Links, not a custom checkout?
The Stripe Payment Links API generates a hosted checkout URL that Stripe manages entirely. No frontend code, no webhook handling for the checkout session, no SSL certificate concerns. The link expires after payment is complete. For a service business sending one-off invoices, it's the right tool.
Custom Checkout Sessions make more sense if you need a branded experience, complex line items, or tight integration with your own backend. For this use case, the extra complexity would have added weeks with no meaningful benefit to the end customer.
Results
- 100+ payment requests processed without manual intervention
- Zero Stripe dashboard access required for billing team members
- Average time from form submission to payment link delivery: under 30 seconds
- Duplicate customer rate dropped to zero after implementing the customer check step
What you can adapt this for
The same pattern works for any workflow where you need to decouple data entry from a sensitive system. Swap Google Forms for an internal tool, Typeform, or an Airtable form. Swap Stripe for any API that accepts an auth token. Make.com acts as the secure bridge — credentials live in Make.com, never in the hands of the person filling the form.