The short version.

There are two working patterns. In the first, a customer-facing web page collects the payment (rendered by Stripe's Elements or hosted Checkout) and the result flows back to FileMaker. In the second, a FileMaker script initiates the payment through the Stripe API — usually by generating a payment link that goes to the customer — and Stripe's webhook informs FileMaker when the payment completes.

Both patterns keep card data entirely off your infrastructure. Both are the boring, well-worn shape thousands of businesses use to run payments through Stripe every day.

Pattern 1: Customer-facing web page.

Use when customers pay themselves — e-commerce checkouts, self-service invoice payment, event registration, service booking. The pattern:

  1. Customer clicks a payment link from an invoice email, a website button, or an SMS.
  2. Their browser loads a payment page hosted by your web extension — a small FastAPI or Node service that renders Stripe's Payment Element inside your branded form.
  3. Customer enters card details. The details go directly to Stripe, never to your server.
  4. Stripe processes the charge and returns a success or failure to the browser.
  5. Independently, Stripe sends a webhook to your service. The service authenticates to FileMaker through the Data API and writes the payment record — updated invoice status, payment date, transaction ID, receipt URL.

The webhook is the reliability layer. It fires regardless of what the customer's browser does after payment. If the browser closes, if the network drops, if the customer clicks away — the webhook still confirms the payment to FileMaker.

Pattern 2: FileMaker-initiated through the API.

Use when a staff member drives the payment — sales-team invoicing, back-office subscription management, refund processing, saved-card charges. The pattern:

  1. A FileMaker script calls the Stripe API. Options include creating a Payment Link (Stripe hosts the payment page for you), creating a Payment Intent for a specific customer, charging a saved payment method, issuing a refund, or managing a subscription.
  2. The script uses either FileMaker's built-in Insert from URL (cURL options) or the MBS plugin's CURL functions. MBS is the more reliable path for anything beyond simple calls, particularly for error handling and TLS behavior.
  3. Stripe returns the response synchronously (for immediate operations like refunds or lookups) or through webhooks (for asynchronous events like customer completing a payment link).
  4. Webhooks arrive at the same small service used in Pattern 1 and write results back to FileMaker.

This pattern lives entirely inside your existing FileMaker workflow. No new user interface. Staff triggers the operation through a familiar layout button; the money flows through Stripe; the receipt lives in FileMaker.

Card data never touches your infrastructure. That is what makes this safe to build.

The PCI reality.

Stripe is PCI-DSS Level 1 certified — the highest tier — which means their infrastructure has been audited and approved to handle card data at scale. When you use Stripe correctly, card details flow from the customer's browser (or their saved payment method) directly to Stripe. Your systems never receive them, never store them, never transmit them.

This keeps your business's PCI scope very narrow. You are not handling cards; you are integrating with a payment processor that is. The paperwork required from you for compliance is small — usually a self-assessment questionnaire (SAQ-A for the light case) — because there is no cardholder data to protect at your end.

What voids this is doing something clumsy — building a form that catches card numbers on your server before "sending them to Stripe," or logging responses that contain card fields, or emailing a copy of a receipt with the full number in it. Any of those things pull your business into full PCI scope. A competent integration never does them; a careless one might. This is one of the reasons the integration is worth building well rather than cheaply.

What it costs.

Stripe fees. As of 2026, standard US card processing is 2.9% + $0.30 per successful charge. International cards, premium cards, and dispute cases have surcharges. No monthly fees for basic operation. Full current pricing lives at stripe.com/pricing.

Build cost. $8,000 to $20,000 for a solid integration, depending on scope. A one-time payment page tied to invoice records is on the low end. Recurring subscriptions with automated dunning, a customer portal, refund processing, and reconciliation reports is on the high end. A full-featured integration in the $15-20k range is typical for a small business that runs meaningful monthly volume.

Ongoing cost. Minimal, once built. Stripe handles the platform side. FileMaker holds the transaction records. Occasional small changes as Stripe updates their API or your business changes — usually covered under a stewardship retainer.

What makes it reliable.

Three things separate a working integration from one that occasionally loses money.

Webhooks, always. Any pattern where the customer's browser is the only source of truth for whether a payment succeeded is not reliable. Webhooks are Stripe's mechanism for telling you what happened, independent of the customer's session. Every serious Stripe integration processes them.

Idempotency. The webhook may fire twice. Your handler needs to recognize duplicate events by their Stripe event ID and not double-post the payment. This is a specific pattern well-documented by Stripe; skipping it produces subtle double-billing bugs that take months to find.

Reconciliation. Once a month, compare what Stripe says happened against what FileMaker says happened. Small drift is normal; large drift means webhooks are being missed. This is a script that runs on a schedule and flags anything that doesn't reconcile.

Common integration points.

  • One-time invoice payment — the most common starting point.
  • Recurring subscriptions with Stripe Billing, synced to a FileMaker Customers or Contracts table.
  • Refund processing initiated from FileMaker, with the result written back to the original invoice.
  • Saved payment methods for repeat customers, so a sales rep can charge a customer's card on file.
  • Stripe's hosted customer portal for customers to manage their own subscriptions and payment methods.
  • Reconciliation report — Stripe activity vs. FileMaker records, monthly.

The webhook is how you make it reliable. The payment page is how you make it work.

What to do next.

The free triage call is where the scope conversation happens. You describe what you're trying to accept payments for, roughly how much volume, whether it's one-time or recurring, and where in the FileMaker system the money would land. Thirty minutes and you'll have a specific number for the build and a sense of which of the two patterns fits your situation.