If you have integrated payment systems: what was harder than expected?
Posted by GaTechThomas@reddit | ExperiencedDevs | View on Reddit | 25 comments
For others who have integrated with payment processors/gateways/APIs — what has actually been the hardest part in practice?
A few things I’d love to understand from people who’ve done it:
What ended up being more painful than expected?
What breaks most often in production?
Which providers had the best/worst docs or developer experience and why?
How much operational/support burden exists after launch?
What kinds of edge cases surprised you?
What differentiates a “good” payments integration from a painful one?
Not recruiting or selling anything.
susmines@reddit
Stripe is by far the best option for DX, docs, support, etc. if your business model can support the fees
meowthor@reddit
What other choice is there for lower cost/fees? I looked at merchant accounts and seems like their pricing is even higher than Stripe.
Neeerp@reddit
Useless answer but if you’re a massive tech company, you can go the route of building your own in house and save a lot of money
niveknyc@reddit
I've been looking into authorize dot net - rates far cheaper
meowthor@reddit
how so? I'm seeing $25 per month + 2.9% + 30¢ per transaction for their 'all in one'. and gateway only is 10c per transaction, but you need to already have a merchant account. the merchant account costs are already about the same as stripe costs. where are you seeing a lower price?
niveknyc@reddit
Yeah that's where I fucked up lol, I only say the transactional rates and thought "Hey I need to look into that", nevermind, I'm an idiot lol
Kaimito1@reddit
Regulations.
Stripe won't touch anything adulty like smoking products.
Had a client that sold e-vapes and Stripe would allow it so had to use Worldpay which allows being used for those types of products
guardian87@reddit
It depends strongly on your markets and expected features. Adyen is a solid alternative, but not cheap either.
In Europe, Mollie is a fantastic PSP.
AJCalcagno_Payments@reddit
Great question. Everyone assumes the initial API handshake is the main hurdle, but the real pain always starts after that first successful transaction. The actual hardest part is state reconciliation and webhook management. Gateways will inevitably drop webhooks, send duplicates, or time out during a capture. If your system expects a perfectly synchronous happy path, you'll end up with massive discrepancies between your database and the processor's reporting.
Managing software vendor integrations in the payments space, the biggest operational burden I see post launch is handling merchant onboarding and lifecycle edge cases like partial refunds on split payments or responding to chargeback notifications. That is exactly where generic integrations break down in production.
A truly "good" integration offloads as much of this state management and compliance liability as possible. Instead of building raw API calls for every single lifecycle event, platforms scale much faster when they rely on a provider's hosted onboarding flows and robust, webhook driven event models to handle the heavy lifting natively. My day to day focus at Payroc is explicitly structuring these kinds of ISV partnerships, ensuring software platforms get the seamless payment capabilities they need without having to engineer those painful reconciliation and onboarding edge cases entirely from scratch. Feel free to shoot me a DM anytime.
dark_mode_everything@reddit
The biggest problem I have faced and still do is that different gateways work in different ways so it's difficult to integrate them in a clean way. You cannot standardise the interface and have each gateway implementing it.
fsk@reddit
Dealing with refunds/chargebacks/fraud.
ehr1c@reddit
I've done a number of different integrations, ranging from drop-in web forms to our own PCI-certified gateway to support retail credit card payments.
EMV hardware certifications. I went in knowing it was going to suck and it somehow sucked so much more than I could ever possibly have imagined.
Pretty rare for things to break but usually it's stupid things like Azure having an outage, some up- or down-stream third party service changing their IP ranges and getting stuck on the WAF, or SSL cert issues on devices.
Adyen's been pretty decent to integrate to, their documentation is more or less intelligent and their developer support teams are pretty responsive. Paymentech and Fiserv are awful, their APIs are ancient and their documentation feels like reading hieroglyphs half the time.
A fair bit. Because of the nature of the integrations they're tough for people without domain knowledge to troubleshoot in too much depth so you get pulled into a lot of issues. Depending on what specific type of integration you're doing you may also have certifications to keep up to date and that process can be a huge time sink.
Certain processors for integrated credit card payments rely on sequence numbers being maintained by the integrator for each set of payment credentials. Those numbers are used in void processing to match a void request to it's original transaction. Turns out if you run into the right kind of race condition your sequence numbers can get out of order, and you end up voiding a bunch of incorrect transactions. Don't ask me how I know.
Documentation and certification requirements.
brian_sword@reddit
It depends on what kind of payment platform you want to integrate with. For example, in most cases, you need to consider idempotency, making sure that you can handle duplicate payments in such errors such as network error etc.
No_Reveal_2455@reddit
We had one that had (probably still has) an XML based (pre-SOAP) API. That was fun...
ehr1c@reddit
Lol was it Fiserv?
ehr1c@reddit
Lol was it Fiserv?
HelenDeservedBetter@reddit
Building a synchronous customer experience on top of a fundamentally asynchronous ecosystem. Some transactions take up to an hour to trigger and up to a week to complete, depending on the bank. You have to think about what the customer will experience and what your business can tolerate in the interims.
Gateway config and address validation rules within 3rd parties.
My business has hundreds of thousands of customer accounts, and we have about 0.5 devs per business day just fixing accounts that got into a bad state or helping customer support answer questions.
Tax rate rounding issues, address validation, invalid combinations of gateway and currency.
A good payment integration is one that customers and non-payment teams within your company don't have to think about. The more people who need to know what's going on under the hood, the more painful it is.
RGBrewskies@reddit
add in multi-country shit ... vat taxes, and currency conversions, and cards that only work in some countries, and 3DS support or whatever the fuck it's called
banking is broken
bitcoin
it_happened_lol@reddit
I've dealt with this domain on-and-off for a decade. It is not an especially difficult domain in my opinion - The payment gateway is doing the hard part. Typically nothing breaks in production, pretty much all payment gateways I've worked with have sublime uptime.
Sure there are warts, other posters have commented on them already. To directly address common responses of pain-points in this thread:
Good reporting and UI/UX within your product allows your operations/support to handle this instead of your devs. You really shouldn't need developers to clean data or work with customers.
Use a saas that specializes in this.
Most payment gateways are similar. The abstraction/interfaces should be fairly straight-forward. Find where they diverge is where you need solid business rules. i.e. Settlement time is 24 hours? Make sure that's represented into your product. Currency is determined at the merchant account level instead of programmatically? Again, business rules, don't let users configure that kind of gateway. Ensure customer documentation states the requirements.
Soggy_Grapefruit9418@reddit
The biggest surprise for me was how much of payments engineering is not the “payment request” itself, but all the weird failure states around it. Webhooks arriving late, duplicate events, disputed charges, partial refunds, regional bank quirks, users closing tabs mid-checkout, etc.
serial_crusher@reddit
The hardest part in practice is when management decides to migrate from one provider to another for purely business reasons even though they don't have functional parity. Then they migrate like 1/3 of your existing customers but the rest get stuck on this old legacy system and you have to maintain both.
Stripe is pretty good, but their developer support sucks. You file a support ticket and generally get a response from an LLM, or it escalates to a human copy/pasting an LLM's output. They have a discord channel for developer support that is useful for questions about how the API works, but when it's things like "how did this payment end up in this unexpected state", they're terrible, but also the best in the market.
Pseudanonymius@reddit
The hardest part is always dealing with their proprietary API's with outdated docs, and going back and forth with their support team because they haven't got their stack right.
guardian87@reddit
Many providers also use really overcomplicated APIs that offer a million functions you don't need. In most cases I would argue that connecting to a PSP is a better technical decision than directly integrating any payment provider.
dabup@reddit
This with any third party SDK I'd think.
Even more stressful when it's payment related though lol
recursive_arg@reddit
As others have said, the hardest part is the back and forth taking forever when reaching out for support.
The second is architecting in a way that it wouldn’t be the end of the world if you ever did have to change servicer. Separating call and data logic from your internal app logic via wrappers, models etc. This seems like a given but you’d be surprised…