Stripe Lead Billing & Payment Automation

Executive Overview & The Problem#

The client operates a lead-generation business where customers receive leads generated through advertising campaigns such as Google Ads and Meta.

The billing model is simple:

A client receives a lead → the lead is delivered → the client is charged for that lead.

The technical challenge was making this workflow secure, automated, and flexible enough to support repeated charges throughout the day.

The client needed a way to collect a customer's card details upfront without charging them immediately, then use the saved payment method later whenever a lead was delivered.

The initial pricing model included:

• Google Calls + Lead Form: $105 per lead
• Meta Lead Form: $69 per lead
• Future support for client-specific pricing and different lead types

The main requirements were:

• Securely collect and save client payment methods
• Never store raw card information in the application
• Charge clients later when leads are delivered
• Support multiple charges throughout the day
• Connect billing activity with GoHighLevel
• Handle successful and failed payments
• Keep the architecture flexible enough to introduce Zapier automation where required

I designed the payment workflow around Stripe SetupIntents for securely saving payment methods and PaymentIntents for processing future charges.

Architectural Approach & System Design#

The architecture separated payment-method collection from payment execution.

This was important because the initial customer interaction should only save the payment method and should not result in an immediate charge.

Payment Method Collection#

The customer starts from a GoHighLevel landing page where payment information is collected.

The payment flow uses Stripe's SetupIntent architecture:

GoHighLevel Landing Page
        │
        ▼
Stripe.js / Secure Card Collection
        │
        ▼
Stripe SetupIntent
        │
        ▼
Payment Method Saved
        │
        ▼
Stripe Customer + Payment Method IDs

The application does not need to store raw card information.

Instead, it works with Stripe references such as:

• Stripe Customer ID
• Stripe Payment Method ID

This keeps sensitive payment information within Stripe's payment infrastructure.

Lead Delivery & Charging Flow#

The second part of the architecture handles the actual billing event.

When a lead is delivered to a client, the system can use that event to initiate a Stripe PaymentIntent.

Google / Meta Lead
        │
        ▼
GoHighLevel
        │
        ▼
Lead Delivered to Client
        │
        ▼
Webhook / Automation Trigger
        │
        ▼
Identify Client
        │
        ▼
Determine Lead Price
        │
        ▼
Stripe PaymentIntent
        │
        ▼
Charge Saved Payment Method

The architecture was designed around a direct webhook-first approach, rather than making Zapier a mandatory dependency for the core payment process.

Zapier could still be used where it makes sense for additional workflow automation.

Flexible Lead Pricing#

The billing logic was designed to keep pricing separate from payment execution.

The initial pricing rules were:

Google Lead → $105
Meta Lead   → $69

This approach also leaves room for future client-specific pricing.

For example, different customers could eventually have different prices for the same lead source or lead type without requiring major changes to the payment infrastructure.

Payment Lifecycle#

Each lead can represent an independent billing event.

Lead Delivered
      │
      ▼
Identify Client
      │
      ▼
Retrieve Stripe Payment Method
      │
      ▼
Calculate Lead Price
      │
      ▼
Create PaymentIntent
      │
      ▼
Confirm Payment
      │
      ├───────────────┐
      ▼               ▼
  Succeeded         Failed
      │               │
      └───────┬───────┘
              ▼
        Update CRM

Using individual PaymentIntents keeps each lead charge independently identifiable and easier to reconcile.

Key Technical Challenges & Solutions#

1. Saving Cards Without Charging Customers#

The biggest requirement was collecting payment information without taking an initial payment.

A traditional payment flow was therefore not suitable for this use case.

I used Stripe's SetupIntent architecture to separate payment-method collection from payment execution.

The customer can provide their card details, Stripe securely handles the payment method setup, and the system retains the necessary Stripe identifiers for future billing.

This means the application does not need to store sensitive card details.

The resulting flow is:

Customer Card
     │
     ▼
Stripe.js
     │
     ▼
SetupIntent
     │
     ▼
Payment Method
     │
     ▼
Stripe Payment Method ID

2. Charging the Same Client Multiple Times#

Clients can receive several leads throughout a single day.

The billing system therefore cannot be designed around a single payment.

Instead, the saved Stripe Payment Method can be associated with multiple future PaymentIntents.

For example:

Client
  │
  ├── Lead #1 → PaymentIntent → $105
  │
  ├── Lead #2 → PaymentIntent → $105
  │
  ├── Lead #3 → PaymentIntent → $69
  │
  └── Lead #4 → PaymentIntent → $105

Each lead becomes its own billing event, giving the business a clear relationship between the delivered lead and its corresponding payment.

3. Connecting Stripe With GoHighLevel#

GoHighLevel manages the lead-generation and client workflow, while Stripe handles payment processing.

Rather than tightly coupling the two systems, I designed the integration around events.

GoHighLevel
     │
     │ Lead Delivered
     ▼
Webhook
     │
     ▼
Payment Processing
     │
     ▼
Stripe
     │
     ├── Payment Succeeded
     │
     └── Payment Failed
     │
     ▼
CRM Status / Automation

This approach keeps Stripe responsible for payment processing while GoHighLevel remains responsible for CRM and lead operations.

It also provides flexibility to introduce Zapier for additional automation without making it responsible for the core payment logic.

Results & Business Impact#

The implementation established the foundation for an automated lead-based billing system.

The completed workflow enabled the business to:

• Collect client payment information without an immediate charge.
• Securely store payment methods through Stripe.
• Work with Stripe Customer and Payment Method IDs instead of raw card information.
• Trigger individual charges when leads are delivered.
• Support different pricing for Google and Meta leads.
• Support repeated charges for the same client throughout the day.
• Connect payment events with the client's GoHighLevel workflow.
• Handle payment success and failure through webhook-based events.
• Keep the architecture flexible for future pricing and automation requirements.

The most important architectural decision was keeping payment processing independent from CRM automation.

Stripe remains responsible for payment security and transaction processing, while GoHighLevel manages leads and customer workflows. Webhooks provide the bridge between the two systems, creating a cleaner and more maintainable integration.