Build vs Buy
Is this core differentiation, can a provider solve it, what does integration cost, what does operating it cost, what happens when the provider fails.
Before "should we build payments ourselves?" can be answered, five questions have to be: is this our core differentiation, can a provider solve it, what does integrating cost, what does operating it cost, and what happens when the provider fails. The answers are the decision; the slogan is not.
"Core" does not mean important; payment is essential and nobody chooses a store for it. Core means the reason a customer picks you — and that is the one thing you cannot buy, because a provider that solves it solves it for your competitors too.
"Build" is estimated for the week it takes; "buy" is estimated for the SDK call. Both are wrong the same way: the cost of a capability is what it takes to connect it and what it takes to live with it, and neither appears in the first estimate.
Every bought capability will fail, be slow, change under you, or rate-limit you — not as a possibility, as a schedule. The build-vs-buy decision owes the design a paragraph for each, and the payment provider and the email provider need very different paragraphs.