Coast Technology
Organizations kept billing customers while we swapped the payment gateway and cloud account
Coast Technology needed a new payment gateway and a new cloud account for the multi tenant invoicing portal we had built for it. We proved the gateway's limits with its own support first, kept card data out of the backend and moved only production, with no rebuild.
B2B SoftwareMulti tenant invoicing and payments portalModernized a live product
The challenge
The portal's payment form had to move to a new gateway and production to a new cloud account, while organizations kept invoicing their customers through it.
What we did
We tested the gateway on a demo account, added a session token service so card data stayed in the gateway's form, ran a QA round and then moved production only.
The outcome
The portal ran on the new gateway and cloud account with the same screens, tenants and data, and Coast heard the gateway's fee limits before release.
- Changed
- Payment gateway, with card and ACH
- Moved
- Production frontend, backend and database
- Kept
- Tokenized cards, tenancy and the live domain
- Not rebuilt
- Portal screens and data model
The starting point
A multi tenant invoicing portal we had built and launched for Coast Technology: organizations billed their customers by email or text, and customers paid online by card or ACH. It had been in production for over a year, with a tokenized card flow.
What had to change
The payment form had to move to a different gateway, and Coast was moving its products to a new cloud account. Both changes had to land inside the running portal, without rebuilding it.
What could not break
- Card data stays in the gateway's own form, and the backend only sees a token
- Each organization keeps its own users, customers, products and invoices
- The service fee stays a separate, disclosed transaction
- The live domain points at a working portal throughout the move
The calls we made
We treated both changes as work on a live product: change the payment layer and the hosting, and keep everything organizations use the same.
- 01
Prove the gateway's limits before advising
Tests on a demo account and emails with the gateway's support confirmed its hosted popup could not add a surcharge or show the service fee, so Coast heard the limit before release, not after.
- 02
A session token service of its own
The new hosted form needs a session token from a whitelisted server, so we ran a small token service on its own instance and had its IP and domain whitelisted by the gateway's support team.
- 03
Show it on a demo first
We deployed a demo environment and recorded a walkthrough, so Coast saw the new payment flow before production changed.
- 04
Move production only
Only the production frontend, backend and managed database moved to the new account, and the demo and dev environments were stopped, which kept the move small.
How the system fits together
What we built
The portal underneath
Our first build, which the swap left in place: a super admin over many organizations, each with its own users, customers, products and invoices, invoices sent by email or text with reminders, and a dashboard of revenue and overdue invoices.
New payment form
The gateway's hosted popup on the payment page, filled with live invoice data, replacing the old form, with card and ACH payments saved to the database as they complete.
Session token service
A token service on its own server, whitelisted by IP and domain by the gateway's support team, with the gateway's payment fields added to each organization's settings.
QA round before release
A QA pass across invoices, products, fees and the payment page, plus responsiveness fixes for the menu, date picker and totals, before anything reached production.
Production move
Frontend, backend and managed database moved to the new cloud account, with the live domain's name servers updated to point at it.
How it works
Open the invoice
The customer opens the invoice from the secure link in their email or text.
Get a session
The portal asks the token service for a session token from the gateway.
Pay in the popup
The gateway's hosted popup takes the card or ACH details, so they never reach the portal.
Record the payment
The backend saves the transaction and its log for the organization's dashboard.
A closer look
What changed
The portal moved to the new gateway and the new cloud account without a rebuild. Organizations kept the same screens, customers and invoices, card data never reached the backend, and Coast knew the new gateway's fee limits before release.
- Five stars
- Client rating
“Great communication and top-notch work. Couldn't be happier.”
Richard DeLanceyCIOCoast TechnologyUnder the hood
- Datics role
- Modernized a live product
- Payments
- The gateway's hosted card and ACH popup, with a session token service whitelisted by IP and domain.
- Card boundary
- Card data stayed in the gateway's form, and the portal stored payments and payment logs only.
- Tenancy
- Each organization saw only its own users, customers, products and invoices, with payment settings per organization.
- Hosting
- React on S3, Node.js on EC2 and PostgreSQL on RDS in the new cloud account, with Route 53 DNS for the live domain.
Data and retrieval
Cloud and infrastructure
Apps and APIs
Also in the stack
How it shipped
Gateway tests
We ran the new gateway on a demo account and checked its fee and ACH behavior with its support team.
Integration
We added the token service and hosted popup, removed the old form and kept the payment records the portal already used.
QA and demo
A QA round fixed what it found, and a demo environment and recorded walkthrough showed Coast the new flow.
Production move
Production moved to the new cloud account with Coast's other products, and the domain was pointed at it.
Facts before advice
We put the gateway's limits to Coast only after confirming them with the gateway's own support, and reported an ACH issue to the gateway directly.
Demo before release
A demo environment and a recorded walkthrough let Coast see the new payment flow before production changed.
One move with its other products
Our DevOps engineer moved the portal as part of Coast's wider move to a new cloud account, with each domain's DNS moved across.
What this unlocked
Changing one layer of a live product while keeping its boundaries is the same discipline we bring when adding AI to products that already run.
Related work
Have a product with the same kind of constraints?
Tell us what already exists and what you want it to do. We will tell you what it takes.