New-Merchant Go-Live Pack
A signed merchant should trigger the same setup every time. Payment webhook provisions folder, SOP doc, CRM and finance rows with duplicate protection. Extensiv / NetSuite client setup is the handoff target—Origin is production-studio provisioning; no WMS account or portal login was built.
- Logistics/3PL
- Stripe
- HubSpot
- Google Drive
- Extensiv
- NetSuite
Overview
The project at a glance
A signed merchant should trigger the same setup every time, not a checklist in someone's inbox. This page documents a payment-triggered provisioning pattern we built: one payment webhook provisions the shared folder, a brief/SOP document, CRM and finance records and a team notification, with duplicate protection and amount flagging — framed for 3PL merchant go-live. Extensiv / NetSuite client setup remains a handoff target, not a delivered step.
Origin pattern: A payment-triggered provisioning pattern built for a production studio, applied to 3PL merchant go-live. No WMS account, client-portal login or store connection was built.
What the engagement had to achieve
- Trigger a consistent go-live pack from a deposit / onboarding-fee payment
- Provision folder, SOP doc, CRM and finance rows the same way every time
- Protect against duplicate webhooks and unexpected amounts
- Notify ops when the pack is ready
- Keep WMS client creation and portal logins out of scope (new work)
The story
Every merchant needs the same setup — and it is still manual
What was at risk
The Challenge
Every new merchant needs a shared folder for SKU lists and SOPs, a kickoff or SOP document, a CRM account, a billing record, and a heads-up to ops. In most 3PLs it is done by hand from a checklist, so steps get skipped, folders get named three different ways, and finance learns about the account when the first invoice is due. Webhooks that fire twice create duplicate folders and billing rows.
Steps skipped, folders named inconsistently, finance last to know.
A repeated payment event provisions twice unless the flow is idempotent.
Creating the merchant in the WMS, issuing portal logins or connecting the merchant's store is new work — see multi-channel sync and catalog ingestion pages.
How we responded
The Solution
A Stripe webhook starts the run (deposit / onboarding fee framing).
A consistently named shared folder per merchant, plus a templated brief / SOP document generated into that folder.
Sales, ops and finance see the same new account; the team is notified when the pack is ready.
Repeated webhooks do not provision twice. Unexpected payment amounts are raised for review instead of processed silently.
Merchant onboarding typically ends in a WMS client record (Extensiv and peers) and an accounting record (QuickBooks and peers). Those writes were not built here.
What we built
The concrete capabilities designed, built, and shipped in this engagement.
Stripe payment webhook as the trigger
A Stripe webhook for the deposit / onboarding fee starts the provisioning run — payment is the gate, not a manual checklist.
Consistently named shared folder per merchant
A provisioned Google Drive workspace with a consistent naming convention per new merchant.
Templated SOP / go-live brief
Google Docs templated brief or merchant SOP generated into that folder.
CRM and finance rows created together
CRM and Finance table rows created so sales, ops and finance see the same new account.
Team notification when the pack is ready
Notification fires when the go-live pack is ready for the onboarding team.
Duplicate protection and amount flagging
Repeated webhooks do not provision twice; unexpected payment amounts are flagged for review instead of processed silently. WMS merchant creation and portal logins are not included.
The stack
The tools behind the build, and the role each one played.
Make.com
Stripe
Google Drive
Google Docs
HubSpot
Extensiv
NetSuite
MercuryGate
FreightPOP
QuickBooks
Descartes
What changed
Beyond the launch
Lasting improvements
The changes that keep paying off after the engagement ended.
- Measured time-to-go-live or hours-saved figures: none claimed
- Design/process outcome: Payment-triggered provisioning — Stripe webhook starts the pack, not a manual kickoff
- Design/process outcome: Duplicate-safe path — repeated webhooks do not provision twice
- Design/process outcome: Amount flagging — unexpected payment amounts raised for review instead of processed silently
Swipe to see more
All case studies
Want an outcome like this one?
A short workflow review maps where automation, AI, or a platform would pay off in your operation — and the first system worth building.