Payment, CRM, Email, and Analytics API Integration Patterns

Every web application integrates with the same core categories of third-party services: payment gateways, CRM systems, transactional email providers, and analytics platforms. While each provider has a unique API, the architectural patterns for integrating them reliably are consistent. This guide covers the correct approach for each category.

1. Payment Gateway Integration (Stripe)

The payment flow is the most critical integration in any commercial application. Mistakes cost real money.

The Correct Pattern:

1. User clicks "Subscribe" on the React/Vue frontend.
2. Frontend calls your backend API (POST /api/checkout)—not Stripe directly.
3. Your backend creates a PaymentIntent via Stripe's API and returns the client_secret to the frontend.
4. The frontend uses Stripe.js (Stripe's official JavaScript library) to show the payment form and collect card details. The card data goes directly to Stripe's servers—never touches your server.
5. On payment success, Stripe sends a payment_intent.succeeded webhook to your server.
6. Your webhook handler verifies the Stripe signature, updates the user's subscription status in the database, and sends a confirmation email via a background job.

Critical Rule: Never rely solely on the frontend success callback to update the user's subscription status. Webhooks are the authoritative source of truth for payment events.

2. CRM Integration (Salesforce / HubSpot)

CRM integrations are typically event-driven: when something happens in your app (a user signs up, upgrades a plan, submits a contact form), you push data to the CRM.

The Correct Pattern:

• Decouple via Events: Do not call the CRM API synchronously in your HTTP request handler. Instead, dispatch a background event: UserSignedUpEvent. A dedicated listener subscribes to this event and handles the CRM API call in a background queue worker.
• Field Mapping Layer: Create a dedicated transformer class that maps your application's data model to the CRM's field schema. This decouples your core application from the CRM's specific format. If you switch CRMs, you only rewrite the transformer, not the entire feature.

3. Transactional Email Integration (SendGrid / Resend)

Transactional emails (password resets, invoice receipts, welcome emails) must be reliable and fast.

• Always Use a Queue: Never call the email provider's API synchronously in an HTTP request handler. Dispatch a SendEmailJob to a background queue. The HTTP handler responds to the user in milliseconds; the email is sent in the background.
• Use Template IDs: Store email templates in your email provider's dashboard (SendGrid's Dynamic Templates), not hardcoded in your application code. Marketers can update email copy without a developer deploying code.
• Process Bounce Webhooks: Configure your email provider to send bounce and spam complaint webhooks to your application. Your webhook handler must mark permanently bounced email addresses as unsubscribable in your database, or your domain's sending reputation will deteriorate.

4. Analytics Integration (Segment / Mixpanel)

• Server-Side Tracking for Critical Events: Do not rely solely on frontend JavaScript to track important business events (e.g., "Subscription Started," "Invoice Paid"). If a user's browser has an ad-blocker, the event is lost. Send critical business events from your backend server, where ad-blockers cannot interfere.
• Consistent Event Naming: Define a naming convention (e.g., Object Action: "Subscription Started," "Invoice Created," "User Invited") and document it in a tracking plan. Inconsistent event names make analytics impossible to interpret.

Building these integrations correctly requires experience with how each provider works in production scenarios. If you need a developer to design and implement these integration patterns, visit my backend API development page.

Building a high-volume integration layer? My Node.js development services cover Bull/BullMQ queues, webhook processing, and concurrent API pipelines.