Getting Started with Stripe: Payment Links, the Dashboard, and n8n Integration

This guide is about getting Stripe working — from account setup through your first automated payment flow in n8n. We’ll cover the dashboard, Payment Links, the test card numbers you need, and how to connect everything to n8n. By the end, you’ll have a working end-to-end flow: n8n creates a payment link, customer pays, Stripe confirms it.

We’re staying in test mode throughout this guide. That’s intentional. Build the whole thing in test, confirm it works, then flip to live mode.

---

Account Setup and Verification

Go to stripe.com and create an account. You’ll need an email and password. Stripe will ask for your business details — country, business type (individual or company), what you sell. In test mode, you don’t need to complete the full verification to start building. You can use test API keys and test cards without submitting a business application.

When you’re ready to go live and charge real money, Stripe will ask for:

• Legal business name and address
• Business type and industry
• Tax identification number (EIN for US businesses, or SSN for sole proprietors)
• Bank account for payouts
• Identity verification for account owners

Complete this before launch day, not the day you want to start taking real payments. Stripe’s verification can take a few hours to a few days, and sometimes they ask for additional documentation.

Finding your API keys

Dashboard → Developers → API Keys. You’ll see two key types:

• Publishable key (pk_test_... in test mode) — Safe to use in client-side code and front-end applications. It identifies your Stripe account but can’t make most API calls.
• Secret key (sk_test_... in test mode) — Used for server-side API calls. Never expose this in front-end code or commit it to a public repository. This is what you’ll use in n8n.

In test mode, both keys start with _test_. In live mode, they start with _live_. Keep these straight. A common mistake is accidentally using a live key in a test workflow or a test key in production. Name your n8n credentials clearly — “Stripe Test” and “Stripe Production” — to avoid this.

---

The Stripe Dashboard

Take a few minutes to know where things live before you start building. The sections you’ll use most:

Home — A summary of recent activity, revenue charts, and any action items Stripe needs from you (like completing verification or responding to a dispute).

Payments — Every payment attempt, successful or failed. Each payment has a detail view with the full event history: created, processing, succeeded or failed, and any refunds issued. This is where you debug payment issues.

Customers — Every customer object you’ve created. If you’re building automation flows properly, every person who pays you should have a Stripe Customer record. This is what ties together their payment history, subscriptions, and saved payment methods.

Products — The catalog of what you sell. Products have Prices attached to them. A single product (e.g., “HVAC Service Call”) can have multiple prices (e.g., $150 standard, $225 after-hours). Products and Prices are the building blocks for both Payment Links and subscriptions.

Subscriptions — Recurring billing. If you’re building a SaaS product or a subscription service, this is where active subscriptions and their billing cycles live.

Reports — Revenue summaries, payout history, and financial reconciliation tools. Useful once you’re live and tracking actual revenue.

The two you’ll check daily when you’re live: Payments (to see what’s coming in) and Customers (to understand your customer base and payment history).

---

Payment Links: The No-Code Way to Accept Payments

A Payment Link is a Stripe-hosted checkout page with a shareable URL. You create it in the Stripe dashboard, share the link, and customers can pay without you writing any front-end code. Stripe handles the entire checkout experience — card input, 3D Secure authentication, payment processing.

Creating a Payment Link manually:

1. Dashboard → Payment Links → Create payment link
2. Click “Add a product” → Create a new product (e.g., “HVAC Service — Standard”) → set a price
3. Configure the link: collect customer email, add your logo, set a success redirect URL
4. Create the link — Stripe gives you a URL like buy.stripe.com/abc123

That URL is permanently shareable. Anyone who clicks it can pay the amount you set. This is what you’d use for a standard service call at a fixed price.

Payment Links vs Checkout Sessions

	Payment Links	Checkout Sessions
Creation	Dashboard or API	API only
URL	Permanent, reusable	Single-use, expires
Amount	Fixed at creation	Dynamic per session
Best for	Fixed-price products, SMS/email sharing	Variable amounts, customer-specific charges

For SendJob, I use both. A fixed-price maintenance visit uses a permanent Payment Link that I store in Supabase and reuse. A job with variable pricing — where the final amount depends on parts and labor — uses a dynamically created Checkout Session or Payment Link created by n8n for that specific job.

---

Creating Payment Links Programmatically via n8n

When the payment amount isn’t fixed — the final cost of a service job depends on what was done — you need to create the payment link dynamically via the Stripe API.

Here’s how to do it in n8n using the HTTP Request node:

Step 1: Create a Price object for the specific amount

Stripe requires a Price object before creating a Payment Link. For variable amounts, you create a one-time price with currency_options and a specific unit amount:

POST https://api.stripe.com/v1/prices

Body (form-encoded):

currency=usd
unit_amount=18500
product_data[name]=HVAC Repair - Job #4821

unit_amount is in cents. $185.00 = 18500.

Step 2: Create the Payment Link with the Price ID

Take the id from the Price response (looks like price_abc123) and use it to create the link:

POST https://api.stripe.com/v1/payment_links

Body:

line_items[0][price]=price_abc123
line_items[0][quantity]=1
metadata[job_id]=4821

The metadata field is critical — this is how you attach your job ID to the Stripe payment so your webhook handler can find the right record in Supabase when the payment comes in.

n8n configuration:

In n8n, use the HTTP Request node with:

• Method: POST
• URL: https://api.stripe.com/v1/payment_links
• Authentication: Basic Auth (username = your Stripe secret key, password = empty)
• Body Content Type: Form Data (Stripe’s API uses form encoding, not JSON)

The response includes a url field — that’s the payment link URL you send to the customer via Twilio SMS.

---

Stripe Test Cards

Before testing with real cards, you need to know the test card numbers Stripe provides. These only work in test mode — they won’t charge anything real.

Card Number	Behavior
4242 4242 4242 4242	Payment succeeds
4000 0000 0000 0002	Payment declined — generic decline
4000 0025 0000 3155	Requires 3D Secure authentication
4000 0000 0000 9995	Declined — insufficient funds
4000 0000 0000 0069	Declined — expired card

For all test cards, use:

• Any future expiry date (e.g., 12/30)
• Any 3-digit CVC (e.g., 123)
• Any billing ZIP code

Test every scenario you can think of before going live. What happens when a card declines? Does your automation handle it? Does the customer get notified? Does the job record get updated correctly? Test the failure paths as thoroughly as the success path.

---

Connecting Stripe to n8n

Adding Stripe as a credential in n8n:

Go to n8n → Credentials → New → HTTP Basic Auth (for HTTP Request nodes) or Stripe API (for n8n’s native Stripe node).

For HTTP Request nodes (my preferred approach):

• Credential Type: HTTP Basic Auth
• Username: your Stripe secret key (sk_test_...)
• Password: (leave blank)

This works because Stripe’s API uses HTTP Basic Auth where the secret key is the username and the password is empty. It’s a quirk of their authentication scheme.

Verify the connection:

Create a simple test workflow: Manual Trigger → HTTP Request → GET https://api.stripe.com/v1/balance with your credential.

A successful response returns your account balance. If you get a 401 error, check that your API key is correct and you’re using the test key (not the live key).

---

Understanding Stripe Customers

Every person who pays you should have a Stripe Customer object. This is not optional for a well-structured automation stack.

A Customer object holds:

• Name and email address
• Payment methods (saved cards)
• Metadata (your Supabase customer ID, job IDs, any custom fields)
• Complete payment history
• Active subscriptions

Why this matters: When you receive a payment_intent.succeeded webhook, you want to know immediately which customer it belongs to. If you’ve been creating Customer objects and attaching your Supabase customer_id in the metadata, that lookup is instant. If you haven’t, you’re left trying to match payment events to customers by email address — messy and error-prone.

Creating a Customer from n8n:

When a new lead is added to Supabase, trigger an n8n workflow that creates a corresponding Stripe Customer:

POST https://api.stripe.com/v1/customers

Body:

email=customer@email.com
name=Maria Santos
metadata[supabase_customer_id]=uuid-from-supabase
phone=+15125551234

Store the returned Stripe Customer ID (cus_abc123) back in your Supabase customer record. Now every time you interact with this customer in Stripe, you reference them by their Stripe customer ID, and Stripe can reference them by their Supabase ID via metadata.

This bidirectional linking is the foundation of keeping Stripe and Supabase in sync. The advanced guide covers the full sync strategy.

---

Reading the Payments Dashboard

Some terminology that trips people up when they first use Stripe:

Payment Intent — The primary object representing an attempt to collect payment. A payment intent has a lifecycle: created → processing → succeeded or requires_payment_method (failed). Think of it as Stripe’s record of “we tried to charge someone.”

Charge — The actual charge to a card. A payment intent typically has one charge attached. The charge has the card details, the amount, and the outcome.

In Stripe’s dashboard, the Payments section shows payment intents. Click into any payment to see its full history — when it was created, when it succeeded or failed, what card was used, and any associated customer or invoice.

Refunds: To issue a refund from the dashboard, open the payment → click “Refund” → enter the amount (full or partial) → confirm. Stripe refunds the cardholder within 5-10 business days. Stripe does not refund the transaction fee. If you charged $150 and refund the full $150, Stripe keeps the $4.65 processing fee. This is standard across all payment processors.

One more thing worth knowing: chargebacks (disputes) are different from refunds. A refund is initiated by you. A chargeback is initiated by the customer through their bank. Chargebacks carry the $15 dispute fee and require you to submit evidence. The advanced guide covers dispute handling.

---

Ready for the real power? Advanced Stripe → covers webhooks, subscriptions, and syncing payment data to Supabase.