Every software platform evaluating a payments provider asks some version of the same question: how long is this going to take us?
It’s the right question, but it usually gets asked the wrong way. People typically want a single number, when the real answer depends on which of two tradeoffs you’re used to.
The trade-off you’ve been offered
Historically, platforms integrating payments have had two options, and neither one is good.
Option one: work with a legacy provider that has antiquated tech, thin or outdated API documentation, and a weekly call that becomes the only channel for getting unstuck. These integrations routinely take 6, 9, even 12 months, which is long enough to kill the business case before you’ve processed a single transaction.
Option two: go the modern, self-serve route and you get up and running fast since the integration itself isn’t the hard part. But once you’re live, you’re on your own to figure out what to actually do with payments. Are you driving adoption? Are you thinking about take rate? Is anyone accountable for turning “we added payments” into “payments moved the business”? For most platforms, the answer is no, because nobody on staff has done this before and the provider’s job ended at go-live.
What integration with Forward actually looks like
Forward’s integration is built to close that gap: fast and supported, from before the contract is signed through the first live transaction and beyond.
If you’ve built a payments integration before, ours is simple. We’ve had partners complete it in a weekend. For a full, soup-to-nuts implementation, six weeks is the outside estimate, not the norm.
Two things make that possible.
The integration starts before the contract
Before a partner ever signs, a Solutions Engineer works with their team to fully map the platform’s use cases to Forward’s technology. This is the solutioning process, and it produces a blueprint detailed enough that a technical team can turn it directly into a product requirements document: which APIs, in what sequence, solving for which edge cases.
Part of that process is deciding what happens now versus what happens later. Not every platform needs every capability on day one, and treating a phased rollout like a failure is how simple integrations turn into year-long slogs. Apple Pay can be phase two. The goal is shipping the capabilities that matter first, not shipping everything at once.
Often, that solutioning process takes a single call. Some partners have finished building against our sandbox before they’ve even signed.
Support doesn’t end at go-live or wait for a scheduled call
Once a partner signs, we open a dedicated Slack channel so their engineers and ours can talk directly, integration-engineer to partner-engineer, instead of waiting for the next weekly sync. That’s on top of the solutions document, API references, SDKs, and webhook documentation everyone gets.
We’re also building this knowledge into something more permanent: an Integration Playbook that consolidates what used to live only in Slack threads and individual Solutions Engineers’ heads, common edge cases, implementation patterns, migration guidance from other providers, into a single guided resource tailored to each partner’s scope. The goal is that the answer to “how do I handle this” exists in a durable place the first time, not just the fifth time someone asks in Slack.
Then it’s sandbox, certification, and live
Partners integrate in a sandbox environment, and we certify that integration against the original solutions document before issuing production credentials. From there, it’s a final test and go-live with the merchant. No guesswork about whether the integration matches what was scoped, because it’s checked against the plan made months earlier.
For platforms just embedding our Elements SDK, that whole path can take a day. One partner converted their entire existing book of business onto Forward in under a month after their integration was complete.
What the process surfaces beyond the integration itself
The solutioning conversations often uncover problems platforms didn’t know they had. A common one: reconciliation friction, where a platform’s accounting team is frustrated because payments aren’t matching up cleanly in QuickBooks. Usually that’s because QuickBooks needs gross settlement, invoice and payment amount matching one-to-one, while the platform’s current setup nets out fees before settling. It’s not a payments problem so much as an implementation problem, and it’s the kind of thing that only surfaces when someone is asking the right questions before build starts, not after.
The real answer to “how long will this take”
The lead engineer at one of the software platforms that recently embedded payments with us put it best:
This was great fun to implement. Kudos to the team for easy-to-use APIs and a sandbox environment that just worked.
The goal shouldn’t be to build every possible capability before going live. It should be to define what success looks like for phase one, build it, validate that it works, and get it into the hands of real customers.
That’s where the difference between a vendor and a partner matters. A legacy provider might hand you documentation and a sandbox, but still take months to get you live. A self-serve provider might get you live quickly, but leave you to figure out what comes next.
Forward works with you to define the first phase before the build starts, gives your team a clear blueprint to execute against, and stays involved through certification, go-live, and what comes next.
So, how long does a payments integration actually take?
Sometimes a weekend. Sometimes a few weeks. But it shouldn’t take six months, and you shouldn’t have to figure it out alone.
