Back to all Cases
Payment Integration Delivered in 3 Weeks with AI-Assisted Development
A client running in-person card payments on Stripe needed a second processor, NMI, added in parallel without touching the existing Stripe flow. The standard estimate was three months. By porting the proven Stripe integration rather than rebuilding, and by giving AI verified API behavior instead of letting it guess, ASD Team validated the full NMI flow in three weeks.
The client had been working with ASD Team for a while. Their platform handled in-person card payments through physical terminals, POS systems, and card readers, with Stripe powering the main payment flow.
As the platform grew, Stripe alone was no longer enough. Processing fees affected merchant margins, and some business categories the client wanted to serve could not use Stripe.
The request was to add NMI as a second processor, running in parallel with Stripe. Existing Stripe logic had to stay untouched, while NMI would give merchants another payment option.
The client also wanted AI involved in development. The usual estimate for this kind of integration was around three months. The target timeline was three weeks.
Stripe is the default for good reason. At scale, though, its limitations become real business constraints. Two mattered most here. The tradeoff: NMI is significantly harder to integrate than Stripe. Less documentation, no ready-made developer tools, minimal industry coverage. Running both in parallel was the right call, Stripe’s ease of use for standard merchants and NMI’s flexibility for everyone else.
- Fees. Stripe’s processing costs are fixed and higher. NMI offers more flexibility and better margins for merchants at volume.
- Merchant fit. NMI gives merchants more flexibility in how they process, widening the range of businesses the platform can serve. This supported the client’s growth plans.
In-person payment flows have more moving parts than online checkout: account setup, terminal registration, payment creation, live status updates, transaction confirmation. Any step failing means payments don’t process. And when something breaks at a physical terminal, it isn’t a support ticket. It’s a customer standing at a counter while the system hangs.
The bigger complication was AI. Stripe and PayPal are well represented in AI training data. NMI is not. We tested this before writing a line of production code: we asked AI to generate an NMI integration with no preparation. The output looked clean and confident, and it called endpoints that don’t exist, invented wholesale.
That is the failure mode of AI on poorly documented systems. It fills the gaps in its knowledge with something that sounds right. In a payment workflow, that surfaces as a transaction that silently fails, with real financial consequences, not a UX problem. This is exactly why “use AI to move faster” required a structured approach, not just prompting and shipping.
- We built a minimal test environment to run real calls against NMI and see how it actually behaved, not how the documentation said it should. This surfaced gaps and inconsistencies that weren’t documented anywhere. Finding them here took days. Finding them later would have cost weeks.
- We connected NMI’s live documentation directly to our AI environment so it was working from verified, current information, not its own assumptions. We confirmed it understood correctly before letting it near the production codebase.
- We gave the AI the validated test environment and the existing Stripe codebase together, with one instruction: same structure, NMI in place of Stripe. The existing integration had already solved the hard problems. AI translated them. A few weeks of back-and-forth to refine the output. This is where most of the time saving came from.
- Some parts required direct investigation, where NMI’s behavior wasn’t documented and no amount of AI prompting would surface the answer. That’s where our developer stepped in. On any niche integration, there are moments where the answer isn’t written down anywhere. That’s where engineering judgment takes over.
“There’s no point doing architecture when you don’t understand what’s happening in reality. We tested the API first — then we brought in AI to perform routine tasks”
— Lead Developer, ASD Team
A complete NMI payment flow running alongside Stripe, validated in a test environment and ready for production:
- Merchant onboarding: account setup and activation through the platform
- Terminal registration: physical card readers paired and ready to process
- Two payment modes: terminal selected upfront or chosen after payment is created
- Real-time payment status: live updates across terminal, browser, and connected POS systems
- Reliable transaction tracking: every payment correctly matched throughout its lifecycle
- Parallel processor setup: NMI alongside Stripe, existing integration untouched
AI was a genuine accelerator, and it was not sufficient on its own. The client asked for AI in the belief it could close the timeline gap. What made it work was the structure around it, not the model itself.
At the start, we asked AI to generate an NMI integration with no preparation, and it produced code that referenced endpoints that don’t exist. Later, once we had verified how the API actually works and given the AI accurate documentation and a working example to follow, the same tool produced code that worked. We didn’t change the AI. We changed what we gave it to work with.
The biggest reason this took 3 weeks instead of 3 months: a working Stripe integration already existed. The hard problems were solved. AI ported them. That is a fundamentally different problem from building from scratch.
When you already have one integration, the second in the same category doesn’t start at zero. What changes is the connection to the new provider, and that is exactly the kind of work AI handles well. The more integrations you have built, the cheaper each new one becomes.
This applies well beyond payments: delivery APIs, booking providers, notification services, data sources. An existing codebase is the starting point, not a constraint.
Have an API integration on your roadmap?
Tell us what you're connecting — we'll give you an honest picture of what's involved.
