Enterprise NetSuite-Integrated Payments Platform

What was on the table

The client — a US-based payment processing provider — had built their original product on the NetSuite platform itself, with payment logic spread across SuiteScripts, a handful of disconnected UIs, and several backend services accumulated over years of feature work.

The architecture had reached its limits:

• The card-processing UI did not allow reliable retries or voids.
• New payment rails on the market (instant payments, FedNow, Plaid Instant) could not be integrated without a parallel backend.
• Customers had no single point of entry into the payments system — some flows required login, some did not, and account state was fragmented across processors.
• Hosting payment workflows inside NetSuite was rate-limited, brittle, and difficult to debug under load.

The mandate was to design and build a replacement platform that could continue running the existing book of business without disruption while opening the architecture to the next decade of products.

What we built

The new platform centers on a Go backend running on AWS, with Temporal orchestrating long-running payment workflows. NetSuite remains the system of record for invoices, customers, and payment events — but it no longer runs the orchestration.

A new payment portal (Vue 3 + TypeScript) gives customers a single entry point for one-time and recurring payments. A separate operations console (Vue 3) gives merchant staff a unified view of transactions, voids, refunds, disputes, and reconciliation.

The card-present terminal flow — a one-page Vue 3 application loaded inside a NetSuite Suitelet — talks to the same Temporal-backed Go service. Status updates are polled at three-second intervals while the workflow runs; the orchestration handles the actual card terminal communication, retry logic, and reconciliation back into NetSuite.

Authentication runs across WebAuthn / FIDO2 (with hardware security keys and biometric credentials), TOTP, and email-verification flows for sensitive account changes. Session management tracks devices and supports remote termination.

How we got there

We worked the migration as a strangler-fig: every new feature shipped against the new platform, while the legacy NetSuite-hosted flows remained operational. Specific care went into:

• Idempotency keys on every transaction-mutating call. Card processing has too many ways to time out for “fire and pray” to ever be acceptable.
• Reversible workflows. Every Temporal activity that touches a real-money operation has a compensating activity defined. If a flow fails partway through, the cleanup is automatic.
• Observability from day one. Structured logging, distributed tracing, and per-merchant dashboards are part of the platform contract — not something that gets added when something breaks.
• PCI scope reduction. Cardholder data flows are tokenized at the earliest possible boundary. The internal services do not see PANs.

What changed for the business

The platform now handles card-present, card-not-present, ACH, and recurring payments through a single backend. New payment rails plug in as additional Temporal activity sets — not as new backends. The customer-facing portal is one product instead of four.

Card-present payment-failure rates dropped substantially as Temporal-based retry replaced the original UI-driven approach. Reconciliation, which previously required manual intervention on edge cases, now runs as a scheduled workflow with exception escalation.

Two of the underlying connectors — for FreedomPay’s Commerce Connect API and for NetSuite RESTlets — are now maintained as open-source Go libraries, available to the broader community.

What this looks like as a service

If you are running payment processing on or near NetSuite and you have hit similar limits — workflows that can’t reliably retry, customers who don’t have a single account, payment rails you can’t integrate — this is the kind of work we do.