What should a payments partner build, and what should your developers build?

Most disappointment in a payments project comes from a line that was never drawn. The provider's sales deck said "we handle everything". The platform's CTO heard "we will not need engineers for this". Six weeks in, a developer is reading an API reference alone at nine at night, and the account manager is explaining that "everything" meant the processing.

The fix is to write down who builds what before anyone starts. Not as a courtesy, but because the two sides are good at different things. A payments partner knows what a soft decline means, how a chargeback arrives, what a payout schedule should do when a refund lands after settlement, and what a customer sign-up flow must collect to pass the checks. Your developers know how your product models a customer, a booking, an invoice and a credit, and where in your screens a payment belongs. Neither side can do the other's job well.

The partner builds the payment products with the platform; the platform's developer builds the platform's own integration against one SDK; a payments engineer sits with that developer throughout.

"Payment products" is a specific phrase. It means the things built on top of the payment that make customers stay: onboarding inside your product, reconciliation into your ledger, payouts to your customers, and the features your customers ask for once those exist, such as deposits taken at booking or refunds from the order screen. "Integration" is also specific: it is the code inside your product that calls the SDK, stores the identifiers, listens to the events and shows the results on your screens. The first is shared work. The second is yours.

There is one thing the rule is not. It is not "the partner builds it for you". No honest partner will write your product's integration, and any that says it will is either describing a referral deal in which your customers sign with someone else, or is about to deliver something your team will have to rewrite.

What sits where, piece by piece. "Partner" is what a payments partner such as Synapto builds with you; "your developer" is your own engineering team or agency; "both" means designed together, with the partner specifying the payments behaviour and your developer building it into your product. Checked October 2026.

It means one person at the partner whose name your developer knows, who has read your product's data model, and who answers the payments questions the day they come up: what a soft decline means and whether to retry it, how to handle a partial capture, which event fires when a chargeback lands and what your product should do with it, why an onboarding check has come back "more information needed" and what to collect.

It does not mean that person writes your code, reviews your pull requests, or stands in for your own engineering lead. The purpose is that nobody on your side is reading documentation alone, and that the same person is there when something breaks after go-live. Most payments integrations fail not on the API but on the dozen small payments-domain decisions a developer has to make without anyone to ask. The payments engineer is the answer to that, and it is the whole of what the partner contributes to the integration itself.

• "Can you just build the integration for us?" No, and you would not want it. Code written by someone who does not know your product is code your team maintains without having written. What a partner can do is specify every payments behaviour precisely enough that your developer never has to guess.
• "Can we skip the reconciliation piece for launch?" You can launch without it, but you will not keep customers without it. Reconciliation is the feature finance teams at your customers notice; a payment that lands with no reference and a netted fee is the first thing they complain about. Build it second if not first.
• "Our provider says they do onboarding, so our developers do not need to build it." They do the checks. Somebody still builds the screens your customer fills in, inside your product, and handles what happens when a check fails. If that somebody is not your developer, your customer is being sent to a third party's form, and a share of them will stop there.

Because the build is your developer's, the date is theirs. A partner that promises a go-live date for your team's work is promising something it cannot see. What a partner can do is scope the pieces in the table with your developer, agree milestones, and say which parts it has built with other platforms before. Scoped with milestones before anything is promised to your customers is the honest version of a timeline, and the only one we give.