Every third-party API integration that breaks silently, fails without alerting, or requires manual reconciliation is an operational cost your team pays indefinitely.

Stripe, Braintree, and Adyen integration for payment capture, subscription billing, refunds, and dispute handling, including the implementation details that prevent production incidents. Stripe integration: PaymentIntent API for card payments with 3D Secure authentication handled transparently (SCA compliance for UK/EU transactions), Stripe Billing for subscription lifecycle management (plan changes, trial periods, proration, dunning), and Stripe Connect for marketplace payment flows where funds need to split between platform and seller. Idempotency key implementation on every charge request: the same idempotency key produces the same result on retry, preventing duplicate charges when network failures cause the response to be lost after the charge succeeds. Webhook processing for all payment lifecycle events (payment_intent.succeeded, payment_intent.payment_failed, invoice.payment_failed, customer.subscription.deleted, dispute.created) with HMAC signature verification on every webhook payload to reject requests not signed by Stripe. PCI DSS scope assessment: Stripe.js and Stripe Elements ensure card data is tokenised in the browser and never touches your servers, keeping you at SAQ A rather than SAQ D compliance scope. Reconciliation logic: payment records from Stripe matched against your internal order management database on a daily schedule, with discrepancy reports flagging payments recorded in Stripe but not in your system (and vice versa) before they accumulate into a month-end accounting problem.

Salesforce, HubSpot, and Microsoft Dynamics integration for contact and account sync, opportunity management, and activity logging from your application back to the CRM so sales reps see user behaviour without switching systems. Salesforce REST API and Bulk API (for high-volume record sync), HubSpot CRM API v3, and Microsoft Dynamics 365 Web API, each with OAuth 2.0 authentication and token refresh handled automatically. SAP integration via RFC/BAPI function calls or SAP REST API (for S/4HANA) for order, inventory, and financial data; Oracle integration via REST APIs or JDBC; NetSuite via SuiteTalk REST or SuiteScript for order-to-cash and procure-to-pay data flows. Bidirectional sync with conflict resolution: when the same record is updated in both systems between sync cycles, the conflict resolution strategy is defined per entity (last-write-wins, source-of-record precedence, field-level merge) and documented as a business rule, not decided ad hoc at implementation time. Data transformation layer: the mapping between external CRM/ERP field schema and your internal data model lives in a single transformation component, when Salesforce renames a field or HubSpot changes an object structure, the update is made in one place rather than scattered across integration call sites. Sync monitoring: record count reconciliation runs after every sync cycle, flagging discrepancies between the expected and actual record counts in each system before they accumulate into data quality debt.

Communications integrations built to handle the delivery reliability requirements of transactional messaging, not fire-and-forget API calls that lose messages silently when the provider has a partial outage. Twilio Messaging API for SMS with delivery status webhooks (delivered, failed, undelivered) written back to your message record so you know which customers received which communications and can suppress redundant sends; WhatsApp Business API via Twilio for markets where WhatsApp is the primary channel; Twilio Voice for IVR and outbound calling with call recording and transcript generation via Twilio's transcription service. SendGrid and Postmark for transactional email: template management via the provider's API (templates versioned so a copy change deploys without a code release), delivery event webhooks (open, click, bounce, spam report) processed and stored against the message record, and unsubscribe management via SendGrid's Suppression Groups or Postmark's Suppression API to ensure unsubscribe requests from any channel are honoured across all future sends. Slack API and Microsoft Teams webhooks for internal notification routing: alerts, workflow notifications, and approval requests delivered to the right channel or user without requiring team members to log into your application for operational updates. Firebase Cloud Messaging for iOS and Android push notifications with topic-based delivery for broadcast notifications and token-based delivery for targeted user notifications. Multi-channel fallback logic: if an SMS fails to deliver, trigger an email fallback automatically, configured per notification type and customer preference.

OAuth 2.0 and OpenID Connect integration with Google (Google Identity Services), Microsoft (MSAL), GitHub, and enterprise identity providers (Okta, Auth0, Azure AD B2C) for social login and workforce SSO, including the PKCE extension for public clients (mobile apps) where client secrets cannot be stored securely. Authorization Code Flow with PKCE used for all user-facing integrations; Client Credentials Flow for machine-to-machine API integrations that authenticate as a service rather than a user. SAML 2.0 for enterprise SSO: integration with corporate IdPs (Okta, Active Directory Federation Services, OneLogin, PingIdentity) so enterprise customers can log into your product using their existing corporate credentials, with SP-initiated and IdP-initiated flows both supported. Attribute mapping from SAML assertions to your user model: NameID, email, department, role, and any custom attributes needed for role assignment or feature gating. SCIM 2.0 for automated user lifecycle management: when a user is added to the enterprise customer's IdP group, they are provisioned in your system with the correct role; when they leave, they are deprovisioned, no manual off-boarding step and no orphaned accounts accumulating in your user table. JWT validation for tokens issued by external IdPs: signature verification against the IdP's JWKS endpoint, claim validation (issuer, audience, expiry), and session management that respects the token's expiry without forcing users to re-authenticate unnecessarily.

Webhook receiver endpoints built to handle production delivery conditions, not just happy-path processing where every delivery succeeds the first time and the provider never retries. HMAC signature verification on every incoming payload: the webhook receiver computes the HMAC-SHA256 of the raw request body using the provider's shared secret and compares it against the Stripe-Signature, X-Hub-Signature-256, or provider-specific header before processing, rejecting any payload where the signature does not match, regardless of how legitimate the payload looks. Idempotent event processing: each webhook event carries a provider-assigned event ID; the receiver stores processed event IDs and checks for duplicates before processing, ensuring that Stripe's delivery retry after a timeout does not produce a duplicate charge record or duplicate notification. Event queue (AWS SQS, RabbitMQ, or Redis with BullMQ) buffers incoming webhook volume between the receiver endpoint (which must respond with HTTP 200 in under 3 seconds to prevent the provider timing out and retrying) and the processing workers (which may take longer). Dead letter queue for events that fail processing after the configured retry count (typically 3-5 attempts with exponential backoff): failed events land in a DLQ with the error context for manual review and replay rather than being silently discarded. Event log with full payload storage and processing status for each event: the audit trail for debugging integration issues and replaying events after a processing bug is fixed. Provider-specific adapters for Stripe, GitHub (webhooks and App events), Shopify (webhooks and admin API), Salesforce (outbound message and streaming API), and custom webhook formats where the provider doesn't follow standard conventions.

Per-integration observability built in from day one, because finding out a third-party integration has been failing for 6 hours via a customer complaint is a support and trust problem that better monitoring would have prevented. Health metrics tracked per integration: HTTP request success rate (2xx vs 4xx vs 5xx by error code), response time at p50/p95/p99 (a p99 spike on a payment API means 1% of your users are waiting 10x longer than average), and rate limit hit frequency (indicating you need to throttle requests or negotiate a higher rate limit tier). Alerting via PagerDuty or Opsgenie: alert when a critical integration's error rate exceeds 5% for 5 consecutive minutes, when p99 response time doubles from baseline for 10 minutes, or when the integration returns a complete outage (100% failure) for more than 2 minutes. Circuit breaker implementation (using Resilience4j, Polly, or a custom state machine): when an external API's error rate exceeds the circuit open threshold, the circuit breaker opens and stops making outgoing calls for a configured cool-down period, preventing your system from accumulating request queue backlog or exhausting connection pools against a clearly unavailable external service. Fallback behaviour defined per integration: a payment processor outage shows the user a "try again in a moment" message rather than an unhandled exception; a shipping rate API outage uses the last cached rate rather than blocking checkout. Integration status dashboard showing current health for every external API dependency in one view, the operational visibility that turns "is the integration broken?" from a 10-minute investigation into a 10-second answer.