Integrating Dynamics 365 with Stripe and PayPal

Taking a payment from inside Dynamics 365 is a request that arrives from every direction: finance wants a "pay now" link on invoices, sales wants deposits on quotes, service wants to charge for a call-out, and the web team wants checkout on a portal. Stripe and PayPal are the two providers most organisations already have accounts with. The integration patterns are well understood, and the first thing to understand is that none of them involve Dynamics 365 ever touching a card number.

The rule that shapes everything

Card data stays with the payment provider. Dynamics 365 sends the provider an amount and a reference, the customer pays on the provider's hosted page or element, and the provider tells Dynamics 365 the outcome. Any design that has card details entering a Dataverse column, a Business Central field, or a canvas app text box is a PCI DSS scope problem and should be stopped before it is built. Business Central's own guidance on credit card handling reflects the same principle.

Pattern 1: pay-by-link on documents

The simplest and most valuable pattern. A sales invoice or quote carries a link to a hosted payment page; the customer clicks, pays, and a webhook from the provider marks the document paid.

In Business Central, the standard payment services feature and the PayPal extension have existed for years for exactly this: a PayPal Payments Standard link on the invoice email and PDF. Stripe is covered by ISV extensions on AppSource that do the same with Stripe Checkout, and some add automated application of the payment to the customer ledger when the webhook arrives. Check whether the extension posts the payment journal for you or only records the reference; the former saves the finance team real time.

In Dynamics 365 Sales, there is no first-party feature. The route is a Power Automate flow that creates a Stripe Payment Link or a PayPal invoice when a quote reaches a stage, writes the URL to the record, and includes it in the email template. The completion webhook, received by an HTTP trigger flow or an Azure Function, updates the quote and, if you have order-to-cash integrated, tells the ERP.

Pattern 2: portal checkout

Customers paying on a Power Pages portal, for a service, a renewal, or an event. Stripe Elements or PayPal Checkout are embedded in the portal page as client-side components, so the card data goes straight to the provider. The portal calls a server-side endpoint, usually an Azure Function, to create the payment intent with the amount from Dataverse and to receive the confirmation. Never create the payment intent client-side with a secret key in the page. See Power Pages for customer portals for the portal side.

Pattern 3: stored payment methods and recurring charges

Subscriptions and repeat billing. The provider stores the payment method and gives you a customer token; Dynamics 365 stores the token, never the card. Charges are initiated server-side against the token, typically from a scheduled Azure Function or a flow that reads due items from Dataverse or Business Central. Stripe Billing and PayPal Subscriptions can run the schedule themselves, in which case Dynamics 365 just receives the invoice-paid events. Decide early which system owns the billing schedule; two systems both generating charges is a refund exercise waiting to happen.

Pattern 4: point of sale and field payments

Dynamics 365 Commerce has its own payment connector framework and certified processors, and Stripe Terminal or PayPal Zettle are not first-class there; if Commerce is in scope, the choice of processor is a Commerce decision. For Field Service technicians taking a payment on site, the practical pattern is a payment link sent by SMS or email from the work order, or a Stripe Terminal reader driven by a separate app, with the result written back through a flow.

Reconciliation is the real integration

The payment succeeding is the easy half. Money arriving in the bank is net of fees, batched daily, and does not match invoice by invoice. Stripe and PayPal both provide payout reports and APIs. The finance team needs a process that imports the payout, applies the individual payments to the customer ledger, and posts the fees. Business Central handles this well through the bank reconciliation and payment journal tooling if the extension records the provider's transaction ID on each payment; without that ID, matching is manual. For F&O, it is a bank statement import plus a matching rule.

Do not consider the integration done until finance can close a month without touching a spreadsheet.

Webhooks and idempotency

Providers retry webhooks. Your receiver will see the same event more than once, and sometimes out of order. Store the provider's event ID and ignore repeats; make the "mark as paid" operation safe to run twice. See idempotency in Dynamics 365 integrations. Verify webhook signatures; an unauthenticated endpoint that marks invoices paid is a fraud vector.

What breaks in practice

Currency mismatches between the document and the provider account. Refunds issued in the provider's dashboard that never reach Dynamics 365. Payment links on documents that were later revised, so the customer pays the old amount. Test mode keys promoted to production. Each of these is a monitoring item, not a rare edge case.

Stability verdict

Pay-by-link and portal checkout are stable, well-trodden patterns with good tooling on both providers' sides. The Business Central extensions are mature; the Sales side is a flow-based build you own. The instability is in reconciliation and in the operational edges, which is where the project time should go.