Microsoft Dynamics GP and Stripe integration

What moves between them

The main flow runs from Stripe into Microsoft Dynamics GP. When a Stripe invoice is created or a payment is charged, ml-connector reads the Stripe event via webhook or polling and posts the corresponding GL journal entry into GP's general ledger, mapped to the customer and GL account in GP. Customer records from Stripe sync into GP's receivables module so that AR invoices reflect Stripe's customer names and billing addresses. Charge amounts and dates post as GL transactions into the revenue and bank accounts in GP. Reference data such as GL account mappings and customer master records are aligned so every Stripe charge lands on a valid GP account.

How ml-connector handles it

ml-connector stores Stripe API keys encrypted and authenticates to Stripe using the secret key via HTTP Basic Auth on each request. On the GP side, it accepts the customer's Windows SBA or SOAP endpoint URL and Windows domain credentials, then uses those to post GL journal entries and create AR invoices in GP. Because GP does not support webhooks, ml-connector listens for Stripe events in real time via registered webhooks but also polls GP periodically to catch any on-premises changes. When a Stripe invoice or charge arrives, ml-connector validates the webhook signature using Stripe's public key, reads the event, maps the Stripe customer to a GP customer record, looks up the correct GL account codes from ml-connector's configuration, and posts a balanced GL entry into GP's unposted (Work) journal. Stripe charge dates become GP transaction dates; amounts are rounded to GP's decimal precision. GL journals are validated against GP's open fiscal periods, so postings to closed periods fail safely with an error message. Every Stripe event is logged with its charge ID, amount, and GL journal reference number so disputes and refunds can be traced. Retries use exponential backoff when GP returns transient errors or rate limits; permanent errors surface to the user via an alert.

A real-world example

A SaaS company runs Microsoft Dynamics GP on-premises for accounting and GL, and uses Stripe to bill customers for subscriptions and one-off charges. Before the integration, the finance team exported a Stripe reconciliation report each day and manually entered the charges and refunds as GL journal entries in GP, then reconciled the GP cash account to Stripe's payout balance at month end. With Stripe and GP connected, each Stripe charge creates a balanced GL journal automatically, posted to the revenue and bank accounts configured for Stripe in GP. Refunds post as reversing entries. The cash account reconciles to Stripe's settlement balance with zero manual work, and month-end close time is cut in half because AR and GL are already aligned.

What you can do

• •Post Stripe invoices and charges as balanced GL journal entries into Microsoft Dynamics GP, mapped to the correct GL accounts and customers.
• •Sync Stripe customer records into GP's customer master and receivables module so billing addresses and names stay current.
• •Validate Stripe webhook signatures using HMAC-SHA256 and refresh GL journals in real time when payments or refunds occur.
• •Handle Windows Active Directory authentication to GP's Service Based Architecture and route requests through your on-premises firewall.
• •Track every Stripe charge and refund with its GL journal reference number and customer for easy reconciliation and dispute tracing.

Questions

Does ml-connector support both Stripe webhooks and polling from Microsoft Dynamics GP?

Yes. ml-connector listens for Stripe webhook events in real time and validates the Stripe-Signature header using your Stripe endpoint secret. Since Microsoft Dynamics GP does not emit webhooks, ml-connector also polls GP on a schedule you define to catch any AR or GL changes made directly in GP. Stripe webhooks are processed immediately; GP polling fills gaps and ensures no transaction is missed.

How does the Windows authentication to GP work when Stripe is cloud-based?

ml-connector stores your Windows domain credentials encrypted and uses them to authenticate to GP's SBA or SOAP endpoint via the Windows Negotiate or NTLM mechanism. You provide the full endpoint URL and domain account once during setup; ml-connector then uses those credentials on every request to post GL journals and customer records into GP. The actual GL posting happens on-premises in GP; Stripe never touches your GP database directly.

What happens if a Stripe charge cannot post to GP due to a closed fiscal period or missing GL account mapping?

ml-connector validates the GL account mapping and fiscal period before posting. If the period is closed or the account does not exist in GP, the charge is marked as failed, an alert is sent to your ml-connector dashboard, and the charge is queued for retry once the period opens or the mapping is corrected. Retries use exponential backoff; you can also manually replay the charge from the audit log once the issue is fixed.