Microsoft Dynamics 365 F&O and PayPal integration

What moves between them

The main flow runs from PayPal into Microsoft Dynamics 365 F&O. ml-connector reads PayPal captures, refunds, and processing fees through the transaction search API and posts the matching journals into the Dynamics general ledger and customer payment journal lines, each mapped to the right main account and financial dimension. PayPal capture and refund webhooks trigger the work as soon as money settles, and a scheduled poll backfills anything a webhook missed and respects the 31-day search window on backfill. A second flow runs the other way: approved vendor payment journal lines in Dynamics drive a PayPal payout batch so suppliers with a PayPal account get paid. PayPal transaction history is read-only, so ml-connector never writes settled records back into PayPal.

How ml-connector handles it

ml-connector stores both credential sets encrypted. For Dynamics it accepts the full environment host per customer, requests an Entra ID bearer token with the client credentials flow scoped to that host, and refreshes it when a call returns 401. For PayPal it Base64-encodes client_id:client_secret, caches the roughly 8-hour token rather than minting one per call, and verifies inbound webhooks by RSA-SHA256 using the certificate from paypal-cert-url after confirming that URL is a paypal.com domain. PayPal captures carry a free-text invoice_id, which ml-connector matches back to the originating Dynamics bill or order so the journal lands on the correct account; fee_amount posts to a fee account. Main accounts and financial dimensions are mapped first, and dimension values are written as the formatted display string Dynamics requires. On backfill the transaction search API caps each request at a 31-day window, and transactions can lag up to 3 hours, so polling is staggered. Dynamics returns HTTP 429 with Retry-After and PayPal returns 429 when traffic looks abusive, so ml-connector backs off and retries; outbound payouts and payment-journal writes carry an idempotency key so a retry never double-pays. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized online retailer with about 150 staff runs Microsoft Dynamics 365 F&O for finance and accounts payable and takes a large share of orders through PayPal. Before the integration, an accountant exported PayPal transaction reports every few days and keyed the captures, refunds, and processing fees into Dynamics by hand, then spent the first days of month-end close reconciling the PayPal balance against the ledger. With Microsoft Dynamics 365 F&O and PayPal connected, each settled capture and refund posts into the general ledger automatically with the processing fee split to its own account, and approved supplier payments pay out through PayPal from the Dynamics payment journal. Month-end close starts with PayPal already reconciled, and the re-keying is gone.

What you can do

• •Post PayPal captures and refunds into the Microsoft Dynamics 365 F&O general ledger, mapped to the correct main accounts and financial dimensions.
• •Split PayPal processing fees to a dedicated fee account so the ledger ties out to the PayPal balance.
• •Match PayPal invoice_id back to the originating Dynamics bill or order for clean reconciliation.
• •Send vendor payouts through PayPal from approved Dynamics vendor payment journal lines, with an idempotency key so retries never double-pay.
• •Bridge PayPal Base64 client credentials and the Microsoft Entra ID bearer token, verify RSA-SHA256 webhooks, and keep a full audit trail on every record.

Questions

Which direction does data move between Microsoft Dynamics 365 F&O and PayPal?

The main flow is PayPal into Dynamics: captures, refunds, and processing fees from PayPal transaction search post into the Dynamics general ledger and customer payment journals. A second flow goes the other way, sending vendor payouts from approved Dynamics payment journal lines out through PayPal. PayPal transaction history is read-only, so ml-connector never writes settled records back into PayPal.

How does the integration reconcile PayPal activity if PayPal has no GL accounts?

PayPal is a payments platform with no GL account or vendor objects, so ml-connector treats the transaction search API as the read-only accounting source. It reads captures, refunds, and fee_amount, then maps each to a Dynamics main account and financial dimension, using the free-text invoice_id on the capture to link back to the originating bill or order. Processing fees are split to their own account so the ledger ties out to the PayPal balance.

How are PayPal webhooks and rate limits handled?

ml-connector verifies every PayPal webhook by RSA-SHA256 using the certificate from paypal-cert-url, after confirming that URL is a paypal.com domain. Capture and refund webhooks trigger posting in near real time, and a scheduled poll backfills any gaps within PayPal's 31-day transaction search window. Both PayPal and Dynamics return HTTP 429 under load, so ml-connector backs off, retries, and caches the PayPal token for its full lifetime to avoid throttling.