[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fVVxUv_DABTT11D478KMlpNMv_sF6z0IeanhDIBRIrFc":3},{"item":4},{"id":5,"idKnowledge":6,"idDomain":7,"idCluster":8,"kindOverride":9,"slug":10,"title":11,"description":12,"bodyMarkdown":13,"bodyHtml":14,"author":15,"date":16,"createdAt":17,"topics":18,"image":26,"hasDownload":27,"fileName":28,"youtubeId":29,"domainCrumb":30,"clusterCrumb":33},"389","21359215-3550-DD44-81A9-5EA4800DE467","E46BDB0A-2979-1E40-93F7-AC40185848A5","33710AE6-6A9E-F741-A6A4-9DFCC5810440","article","how-to-connect-filemaker-to-mollie","How to connect FileMaker to Mollie","A practical guide to linking FileMaker with Mollie for online payments, invoices and subscriptions — including webhooks, API keys and common pitfalls.","You've got customers who want to pay an invoice online with iDEAL, a credit card, or a subscription — but your FileMaker system can only print a PDF and email it. Someone then has to manually check the bank account, match the payment to the right invoice, and update the record by hand. If that sounds familiar, you're not alone: it's one of the most common gaps in custom-built business systems that grew up around quotes, orders and invoicing but were never built for online payment collection.\n\nThis article walks through exactly how to connect FileMaker to Mollie, what the payment flow looks like in practice, and the mistakes that trip up most first-time integrations.\n\n## What is Mollie, and why do FileMaker users connect to it?\n\nMollie is a European payment service provider (PSP) that lets businesses accept iDEAL, credit card, Bancontact, PayPal, SEPA direct debit, Apple Pay and several other payment methods through a single API. It's popular with Dutch and Belgian SMEs because it's easy to set up, has transparent pricing, and — critically for custom software builders — has a clean, well-documented REST API.\n\nFileMaker, on its own, has no native payment gateway. So when a business wants customers to be able to pay an invoice, deposit, or subscription directly from a FileMaker-generated document or portal, Mollie is one of the most practical bridges: it's an API-first service, which fits naturally into FileMaker's `Insert from URL` and `curl` capabilities.\n\nTypical scenarios where Loggix has built this kind of connector:\n\n- A wholesaler wants customers to pay a deposit online before an order is produced.\n- A membership organization needs recurring subscription payments collected automatically, with FileMaker as the membership database.\n- A service company sends invoices from FileMaker and wants a \"Pay now\" link embedded in the PDF or email.\n- An e-commerce backend built in FileMaker needs real-time payment status without staff checking a bank statement.\n\n## How does the FileMaker-to-Mollie payment flow actually work?\n\nAt a technical level, it's a request-response cycle plus an asynchronous webhook. It helps to think of it in four steps:\n\n1. **FileMaker creates a payment request.** Your script calls the Mollie API (`POST \u002Fpayments`) with the amount, description, and a redirect URL — essentially telling Mollie \"a customer needs to pay €249.00 for invoice INV-1042.\"\n2. **Mollie returns a checkout URL.** FileMaker stores this URL and can display it as a clickable link in a portal, embed it in a PDF, or send it by email.\n3. **The customer pays.** They're taken to Mollie's hosted checkout page, choose iDEAL, card, or another method, and complete the payment outside of FileMaker entirely — which is actually a feature, not a limitation: it means your FileMaker system never touches card numbers or bank credentials, so PCI-DSS scope stays out of your solution.\n4. **Mollie notifies FileMaker via webhook.** Once the payment status changes (paid, failed, expired, or refunded), Mollie sends a callback to a webhook URL you registered. This is what actually updates the invoice status in FileMaker — not the customer's browser redirect, which is easy to fake or interrupt.\n\n\u003Cimg src=\"\u002Fapi\u002Fknowledge\u002Finline-image\u002F276?w=700&f=webp\" alt=\"FileMaker sending a payment request to Mollie, customer paying, webhook returning status\" loading=\"lazy\" class=\"w-full sm:w-1\u002F3 sm:float-left sm:mr-7 mb-5 rounded-2xl border border-[#E8E8ED] bg-[#F5F5F7]\" \u002F>\n\nThat last point is one of the most misunderstood parts of this integration, so it's worth repeating: **never mark an invoice as paid based on the redirect URL alone.** A customer can close the browser tab after paying, or before paying, and land on your \"thank you\" page regardless. The webhook is the only source of truth.\n\n## What do you need before you start building the connector?\n\n- **A Mollie account** with at least one active profile (test mode is fine to start).\n- **API keys** — Mollie gives you a live key and a test key. Always build and test against the test key first; test payments simulate every possible status (paid, failed, expired, canceled) without moving real money.\n- **A publicly reachable webhook endpoint.** FileMaker Server needs to receive the webhook call somewhere. This is usually done through the FileMaker Data API combined with a small script step exposed via a PHP or Node.js listener, or directly if you're running FileMaker Server with a custom web endpoint that triggers a server-side script via the FileMaker Admin API or a scheduled script that polls Mollie's status endpoint as a fallback.\n- **A field structure to track payment state**: at minimum a Mollie payment ID, status, amount, method, and last-updated timestamp per invoice or order record.\n- **HTTPS everywhere.** Mollie will not send webhooks to plain HTTP endpoints, and you shouldn't want it to.\n\n## Step-by-step: how do you build the connection in FileMaker?\n\n1. **Create a Mollie API key** in the Mollie dashboard under Developers > API keys. Store the test and live keys as FileMaker security-protected variables or in a dedicated settings table — never hard-code them into scripts.\n2. **Build a script that creates a payment.** Use `Insert from URL` with cURL options to POST to `https:\u002F\u002Fapi.mollie.com\u002Fv2\u002Fpayments`, sending JSON with `amount`, `description`, `redirectUrl`, and `webhookUrl`.\n3. **Parse the JSON response** using `JSONGetElement` to extract the payment `id` and the `checkoutUrl`, and store both on the invoice record.\n4. **Present the checkout link** to the customer — as a button in a customer portal, a QR code, or a hyperlink in the emailed PDF invoice.\n5. **Build the webhook receiver.** Since FileMaker Server can't natively listen on an open web port, most implementations use a small middleware script (PHP, Node.js, or a FileMaker Data API call triggered by a lightweight web server) that receives Mollie's POST call and immediately calls back into FileMaker — either via the Data API or by writing to a queue table that a server-side script checks every minute.\n6. **On webhook receipt, call `GET \u002Fpayments\u002F{id}`** to fetch the authoritative status directly from Mollie — never trust the payload of the webhook call itself, since it only tells you \"something changed,\" not what.\n7. **Update the FileMaker record** with the new status and trigger any downstream logic: marking an order as \"ready for production,\" sending a payment confirmation email, or releasing a subscription license.\n8. **Log everything.** Store the raw API responses (at least temporarily) in a log table. When a client calls asking \"why wasn't my payment registered,\" this log is what saves you an afternoon of guessing.\n\n## What about recurring payments and subscriptions?\n\nMollie supports recurring charges through its **Subscriptions API**, which requires a **first payment with mandate**, e.g. a SEPA direct debit or card payment where the customer explicitly authorizes future charges. Once that mandate exists, FileMaker can trigger Mollie to charge the customer automatically on a schedule — monthly membership fees, quarterly service contracts, or installment plans — without the customer re-entering payment details each time.\n\nThe practical gotcha here: mandates can be revoked or expire, and cards can be declined on renewal. Build your FileMaker logic to handle a failed recurring charge gracefully — a dunning email sequence and an automatic retry after a few days work far better than silently failing and hoping someone notices the outstanding balance.\n\n## What commonly goes wrong in these integrations?\n\n- **Treating the redirect as confirmation.** Covered above, but it's the single most common bug Loggix sees in first attempts at this connector.\n- **Forgetting test vs. live key mismatches.** A payment created with a test key will never show up when checking with the live key, and vice versa — this looks like \"the webhook isn't firing\" but is actually a key mismatch.\n- **No fallback polling.** Webhooks occasionally fail to arrive (network blips, server downtime). A nightly script that checks the status of any payment still marked \"open\" after 24 hours catches these silently missed updates.\n- **Currency and amount formatting.** Mollie expects amounts as strings with two decimals (e.g. `\"10.00\"`, not `10`). A surprising number of failed API calls trace back to this one formatting detail.\n- **Ignoring webhook retries.** Mollie will retry a webhook call if your endpoint doesn't respond correctly. Make sure your receiving script always returns an HTTP 200, even if it queues the actual processing for later — otherwise you can end up processing the same payment update multiple times.\n\n## FileMaker, Klai, and FmBetterforms — where do they fit in?\n\nBeyond the core Mollie API connection, a few tools commonly show up around this kind of build:\n\n- **FileMaker** itself handles the business logic — invoice records, order status, customer data — and is where the payment status ultimately needs to live so staff and reports can act on it.\n- **Klai** and similar AI-assisted development tools are increasingly used to speed up writing and debugging the JSON parsing and cURL scripting that this kind of API integration requires, which used to be one of the more tedious parts of building a Mollie connector by hand.\n- **FmBetterforms** is relevant when you want the *customer-facing* side of this flow — the invoice, order form, or payment request — to look like a modern, mobile-friendly web page rather than a native FileMaker layout. Since the customer never actually needs the FileMaker interface (they're redirected to Mollie's own checkout page), FmBetterforms is more useful for the surrounding customer portal: showing invoice history, outstanding balances, and payment links in a clean web view built on top of the same FileMaker data.\n\n## Checklist: is your Mollie connector production-ready?\n\n- [ ] Test key and live key are stored separately and never mixed\n- [ ] Webhook status is only trusted after a `GET \u002Fpayments\u002F{id}` confirmation call\n- [ ] A fallback polling script checks stale \"open\" payments daily\n- [ ] Amounts are formatted as strings with two decimals\n- [ ] Webhook receiver always returns HTTP 200 promptly\n- [ ] Payment logs are kept for at least a few months for support\u002Faudit purposes\n- [ ] Recurring payment failures trigger a dunning process, not silence\n- [ ] Customer-facing checkout links are tested on mobile, not just desktop\n\n## FAQ\n\n**Does FileMaker need a plug-in to connect to Mollie?**\nNo. Mollie's REST API works fine with FileMaker's built-in `Insert from URL` and JSON functions (available since FileMaker 16\u002F17). A plug-in can simplify things, but it's not required.\n\n**Can FileMaker Server receive webhooks directly?**\nNot out of the box — FileMaker Server isn't a general-purpose web server. Most implementations route the webhook through a small middleware layer (a lightweight script on a web server, or the FileMaker Data API) that then updates FileMaker.\n\n**Is Mollie PCI-DSS compliant, and does that cover my FileMaker system?**\nMollie is fully PCI-DSS compliant for the payment page itself. Since the customer enters payment details on Mollie's hosted page, not inside FileMaker, your FileMaker system generally stays out of PCI scope — one of the practical advantages of this architecture.\n\n**How long does a typical FileMaker–Mollie integration take to build?**\nA one-off payment flow (create payment, redirect, webhook update) is usually a matter of days for an experienced FileMaker developer. Recurring subscriptions, retry logic, and a polished customer portal add more time — budget for a few weeks if you want it production-hardened.\n\nIf your FileMaker system is still relying on manual bank checks to confirm who's paid, this is exactly the kind of gap Loggix builds custom connectors for — alongside broader work on [connecting FileMaker to modern applications and services](https:\u002F\u002Floggix.com\u002Fen\u002Fblog\u002Fhow-to-connect-filemaker-to-modern-applications-and-services). Whether you need a straightforward one-off payment link, a full recurring billing flow, an AI-assisted script to speed up development, or a modern customer-facing portal built with tools like FmBetterforms, it's worth mapping out the right approach before you start writing API calls — and that's a conversation Loggix is happy to have.","\u003Cp>You've got customers who want to pay an invoice online with iDEAL, a credit card, or a subscription — but your FileMaker system can only print a PDF and email it. Someone then has to manually check the bank account, match the payment to the right invoice, and update the record by hand. If that sounds familiar, you're not alone: it's one of the most common gaps in custom-built business systems that grew up around quotes, orders and invoicing but were never built for online payment collection.\u003C\u002Fp>\n\u003Cp>This article walks through exactly how to connect FileMaker to Mollie, what the payment flow looks like in practice, and the mistakes that trip up most first-time integrations.\u003C\u002Fp>\n\u003Ch2>What is Mollie, and why do FileMaker users connect to it?\u003C\u002Fh2>\n\u003Cp>Mollie is a European payment service provider (PSP) that lets businesses accept iDEAL, credit card, Bancontact, PayPal, SEPA direct debit, Apple Pay and several other payment methods through a single API. It's popular with Dutch and Belgian SMEs because it's easy to set up, has transparent pricing, and — critically for custom software builders — has a clean, well-documented REST API.\u003C\u002Fp>\n\u003Cp>FileMaker, on its own, has no native payment gateway. So when a business wants customers to be able to pay an invoice, deposit, or subscription directly from a FileMaker-generated document or portal, Mollie is one of the most practical bridges: it's an API-first service, which fits naturally into FileMaker's \u003Ccode>Insert from URL\u003C\u002Fcode> and \u003Ccode>curl\u003C\u002Fcode> capabilities.\u003C\u002Fp>\n\u003Cp>Typical scenarios where Loggix has built this kind of connector:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>A wholesaler wants customers to pay a deposit online before an order is produced.\u003C\u002Fli>\n\u003Cli>A membership organization needs recurring subscription payments collected automatically, with FileMaker as the membership database.\u003C\u002Fli>\n\u003Cli>A service company sends invoices from FileMaker and wants a "Pay now" link embedded in the PDF or email.\u003C\u002Fli>\n\u003Cli>An e-commerce backend built in FileMaker needs real-time payment status without staff checking a bank statement.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>How does the FileMaker-to-Mollie payment flow actually work?\u003C\u002Fh2>\n\u003Cp>At a technical level, it's a request-response cycle plus an asynchronous webhook. It helps to think of it in four steps:\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>FileMaker creates a payment request.\u003C\u002Fstrong> Your script calls the Mollie API (\u003Ccode>POST \u002Fpayments\u003C\u002Fcode>) with the amount, description, and a redirect URL — essentially telling Mollie "a customer needs to pay €249.00 for invoice INV-1042."\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Mollie returns a checkout URL.\u003C\u002Fstrong> FileMaker stores this URL and can display it as a clickable link in a portal, embed it in a PDF, or send it by email.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>The customer pays.\u003C\u002Fstrong> They're taken to Mollie's hosted checkout page, choose iDEAL, card, or another method, and complete the payment outside of FileMaker entirely — which is actually a feature, not a limitation: it means your FileMaker system never touches card numbers or bank credentials, so PCI-DSS scope stays out of your solution.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Mollie notifies FileMaker via webhook.\u003C\u002Fstrong> Once the payment status changes (paid, failed, expired, or refunded), Mollie sends a callback to a webhook URL you registered. This is what actually updates the invoice status in FileMaker — not the customer's browser redirect, which is easy to fake or interrupt.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cimg src=\"\u002Fapi\u002Fknowledge\u002Finline-image\u002F276?w=700&f=webp\" alt=\"FileMaker sending a payment request to Mollie, customer paying, webhook returning status\" loading=\"lazy\" class=\"w-full sm:w-1\u002F3 sm:float-left sm:mr-7 mb-5 rounded-2xl border border-[#E8E8ED] bg-[#F5F5F7]\" \u002F>\n\n\u003Cp>That last point is one of the most misunderstood parts of this integration, so it's worth repeating: \u003Cstrong>never mark an invoice as paid based on the redirect URL alone.\u003C\u002Fstrong> A customer can close the browser tab after paying, or before paying, and land on your "thank you" page regardless. The webhook is the only source of truth.\u003C\u002Fp>\n\u003Ch2>What do you need before you start building the connector?\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>\u003Cstrong>A Mollie account\u003C\u002Fstrong> with at least one active profile (test mode is fine to start).\u003C\u002Fli>\n\u003Cli>\u003Cstrong>API keys\u003C\u002Fstrong> — Mollie gives you a live key and a test key. Always build and test against the test key first; test payments simulate every possible status (paid, failed, expired, canceled) without moving real money.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>A publicly reachable webhook endpoint.\u003C\u002Fstrong> FileMaker Server needs to receive the webhook call somewhere. This is usually done through the FileMaker Data API combined with a small script step exposed via a PHP or Node.js listener, or directly if you're running FileMaker Server with a custom web endpoint that triggers a server-side script via the FileMaker Admin API or a scheduled script that polls Mollie's status endpoint as a fallback.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>A field structure to track payment state\u003C\u002Fstrong>: at minimum a Mollie payment ID, status, amount, method, and last-updated timestamp per invoice or order record.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>HTTPS everywhere.\u003C\u002Fstrong> Mollie will not send webhooks to plain HTTP endpoints, and you shouldn't want it to.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>Step-by-step: how do you build the connection in FileMaker?\u003C\u002Fh2>\n\u003Col>\n\u003Cli>\u003Cstrong>Create a Mollie API key\u003C\u002Fstrong> in the Mollie dashboard under Developers > API keys. Store the test and live keys as FileMaker security-protected variables or in a dedicated settings table — never hard-code them into scripts.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Build a script that creates a payment.\u003C\u002Fstrong> Use \u003Ccode>Insert from URL\u003C\u002Fcode> with cURL options to POST to \u003Ccode>https:\u002F\u002Fapi.mollie.com\u002Fv2\u002Fpayments\u003C\u002Fcode>, sending JSON with \u003Ccode>amount\u003C\u002Fcode>, \u003Ccode>description\u003C\u002Fcode>, \u003Ccode>redirectUrl\u003C\u002Fcode>, and \u003Ccode>webhookUrl\u003C\u002Fcode>.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Parse the JSON response\u003C\u002Fstrong> using \u003Ccode>JSONGetElement\u003C\u002Fcode> to extract the payment \u003Ccode>id\u003C\u002Fcode> and the \u003Ccode>checkoutUrl\u003C\u002Fcode>, and store both on the invoice record.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Present the checkout link\u003C\u002Fstrong> to the customer — as a button in a customer portal, a QR code, or a hyperlink in the emailed PDF invoice.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Build the webhook receiver.\u003C\u002Fstrong> Since FileMaker Server can't natively listen on an open web port, most implementations use a small middleware script (PHP, Node.js, or a FileMaker Data API call triggered by a lightweight web server) that receives Mollie's POST call and immediately calls back into FileMaker — either via the Data API or by writing to a queue table that a server-side script checks every minute.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>On webhook receipt, call \u003Ccode>GET \u002Fpayments\u002F{id}\u003C\u002Fcode>\u003C\u002Fstrong> to fetch the authoritative status directly from Mollie — never trust the payload of the webhook call itself, since it only tells you "something changed," not what.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Update the FileMaker record\u003C\u002Fstrong> with the new status and trigger any downstream logic: marking an order as "ready for production," sending a payment confirmation email, or releasing a subscription license.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Log everything.\u003C\u002Fstrong> Store the raw API responses (at least temporarily) in a log table. When a client calls asking "why wasn't my payment registered," this log is what saves you an afternoon of guessing.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch2>What about recurring payments and subscriptions?\u003C\u002Fh2>\n\u003Cp>Mollie supports recurring charges through its \u003Cstrong>Subscriptions API\u003C\u002Fstrong>, which requires a \u003Cstrong>first payment with mandate\u003C\u002Fstrong>, e.g. a SEPA direct debit or card payment where the customer explicitly authorizes future charges. Once that mandate exists, FileMaker can trigger Mollie to charge the customer automatically on a schedule — monthly membership fees, quarterly service contracts, or installment plans — without the customer re-entering payment details each time.\u003C\u002Fp>\n\u003Cp>The practical gotcha here: mandates can be revoked or expire, and cards can be declined on renewal. Build your FileMaker logic to handle a failed recurring charge gracefully — a dunning email sequence and an automatic retry after a few days work far better than silently failing and hoping someone notices the outstanding balance.\u003C\u002Fp>\n\u003Ch2>What commonly goes wrong in these integrations?\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>\u003Cstrong>Treating the redirect as confirmation.\u003C\u002Fstrong> Covered above, but it's the single most common bug Loggix sees in first attempts at this connector.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Forgetting test vs. live key mismatches.\u003C\u002Fstrong> A payment created with a test key will never show up when checking with the live key, and vice versa — this looks like "the webhook isn't firing" but is actually a key mismatch.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>No fallback polling.\u003C\u002Fstrong> Webhooks occasionally fail to arrive (network blips, server downtime). A nightly script that checks the status of any payment still marked "open" after 24 hours catches these silently missed updates.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Currency and amount formatting.\u003C\u002Fstrong> Mollie expects amounts as strings with two decimals (e.g. \u003Ccode>"10.00"\u003C\u002Fcode>, not \u003Ccode>10\u003C\u002Fcode>). A surprising number of failed API calls trace back to this one formatting detail.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Ignoring webhook retries.\u003C\u002Fstrong> Mollie will retry a webhook call if your endpoint doesn't respond correctly. Make sure your receiving script always returns an HTTP 200, even if it queues the actual processing for later — otherwise you can end up processing the same payment update multiple times.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>FileMaker, Klai, and FmBetterforms — where do they fit in?\u003C\u002Fh2>\n\u003Cp>Beyond the core Mollie API connection, a few tools commonly show up around this kind of build:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>FileMaker\u003C\u002Fstrong> itself handles the business logic — invoice records, order status, customer data — and is where the payment status ultimately needs to live so staff and reports can act on it.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Klai\u003C\u002Fstrong> and similar AI-assisted development tools are increasingly used to speed up writing and debugging the JSON parsing and cURL scripting that this kind of API integration requires, which used to be one of the more tedious parts of building a Mollie connector by hand.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>FmBetterforms\u003C\u002Fstrong> is relevant when you want the \u003Cem>customer-facing\u003C\u002Fem> side of this flow — the invoice, order form, or payment request — to look like a modern, mobile-friendly web page rather than a native FileMaker layout. Since the customer never actually needs the FileMaker interface (they're redirected to Mollie's own checkout page), FmBetterforms is more useful for the surrounding customer portal: showing invoice history, outstanding balances, and payment links in a clean web view built on top of the same FileMaker data.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>Checklist: is your Mollie connector production-ready?\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Test key and live key are stored separately and never mixed\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Webhook status is only trusted after a \u003Ccode>GET \u002Fpayments\u002F{id}\u003C\u002Fcode> confirmation call\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> A fallback polling script checks stale "open" payments daily\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Amounts are formatted as strings with two decimals\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Webhook receiver always returns HTTP 200 promptly\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Payment logs are kept for at least a few months for support\u002Faudit purposes\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Recurring payment failures trigger a dunning process, not silence\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Customer-facing checkout links are tested on mobile, not just desktop\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>FAQ\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>Does FileMaker need a plug-in to connect to Mollie?\u003C\u002Fstrong>\nNo. Mollie's REST API works fine with FileMaker's built-in \u003Ccode>Insert from URL\u003C\u002Fcode> and JSON functions (available since FileMaker 16\u002F17). A plug-in can simplify things, but it's not required.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Can FileMaker Server receive webhooks directly?\u003C\u002Fstrong>\nNot out of the box — FileMaker Server isn't a general-purpose web server. Most implementations route the webhook through a small middleware layer (a lightweight script on a web server, or the FileMaker Data API) that then updates FileMaker.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Is Mollie PCI-DSS compliant, and does that cover my FileMaker system?\u003C\u002Fstrong>\nMollie is fully PCI-DSS compliant for the payment page itself. Since the customer enters payment details on Mollie's hosted page, not inside FileMaker, your FileMaker system generally stays out of PCI scope — one of the practical advantages of this architecture.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>How long does a typical FileMaker–Mollie integration take to build?\u003C\u002Fstrong>\nA one-off payment flow (create payment, redirect, webhook update) is usually a matter of days for an experienced FileMaker developer. Recurring subscriptions, retry logic, and a polished customer portal add more time — budget for a few weeks if you want it production-hardened.\u003C\u002Fp>\n\u003Cp>If your FileMaker system is still relying on manual bank checks to confirm who's paid, this is exactly the kind of gap Loggix builds custom connectors for — alongside broader work on \u003Ca href=\"https:\u002F\u002Floggix.com\u002Fen\u002Fblog\u002Fhow-to-connect-filemaker-to-modern-applications-and-services\">connecting FileMaker to modern applications and services\u003C\u002Fa>. Whether you need a straightforward one-off payment link, a full recurring billing flow, an AI-assisted script to speed up development, or a modern customer-facing portal built with tools like FmBetterforms, it's worth mapping out the right approach before you start writing API calls — and that's a conversation Loggix is happy to have.\u003C\u002Fp>\n","Jeroen","2026-07-24",1784901678000,[19,20,21,22,23,24,25],"FileMaker Mollie integration","online payments","API connection","webhooks","recurring payments","subscription billing","FileMaker Data API","\u002Fapi\u002Fknowledge\u002Fimage\u002F389\u002F?v=6acd78538f0a",false,"",null,{"title":31,"slug":32},"FileMaker and Claris","filemaker-and-claris",{"title":34,"slug":35},"How to connect FileMaker to modern applications and services","how-to-connect-filemaker-to-modern-applications-and-services"]