The short version.

There are two working patterns. In the first, the customer pays on a web page, with Stripe's own card form on your page or theirs, and the result comes back to FileMaker. In the second, FileMaker starts the payment, usually by creating a payment link that goes to the customer, and Stripe tells FileMaker when it's paid.

Both patterns keep card data entirely off your computers and servers. 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 opens a payment page run by a small web service of yours, with Stripe's card form inside your own design.
  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 signs in to FileMaker and writes the payment record — updated invoice status, payment date, transaction ID, receipt URL.

That notice from Stripe (a webhook) is what makes it reliable. 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 step or the MBS plug-in. MBS is more dependable for anything beyond simple calls, mainly in handling errors and secure connections.
  3. Stripe answers right away for things like refunds and lookups, and sends a notice later for things that happen later, like a customer paying a 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 computers or servers. That is what makes this safe to build.

Card-security rules (PCI).

PCI is the card industry's security rulebook. Stripe meets its highest level, Level 1, which means its systems are 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.

So very little of the rulebook applies to you. You don't handle cards; Stripe does. Your paperwork is usually one short self-assessment form (the SAQ-A), because there are no card numbers on your side to protect.

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 one of those puts your business under the full rulebook. 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 sets the size of the job.

Stripe fees. Stripe charges per successful charge, with surcharges for international cards, premium cards and disputes, and no monthly fee for basic operation. Current rates live at stripe.com/pricing.

The build. Scope decides it. A one-time payment page tied to invoice records is the small end. Recurring subscriptions with automatic reminders when a card payment fails, a customer portal, refund processing, and reconciliation reports are the large end. The System Assessment ends in a quote with three options for your scope.

Ongoing. 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. If the only proof a payment went through is what the customer's browser reported, it isn't reliable. A webhook is Stripe telling you directly what happened, whatever the browser did. Every serious Stripe integration processes them.

Idempotency: safe to receive twice. Stripe may send the same notice twice. FileMaker needs to spot a repeat by its Stripe ID and not record the payment twice. Stripe documents how; skipping it produces quiet double entries 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 gets you a real build number and the pattern that fits.