Well on my first job we had to integrate payment gateways in client apps for online payment. On my second week in office I published an app on the play store with payment gateway credentials for a different client cause they were there as default values. So the money for one client would go to the other. Nobody noticed it for two weeks and when they did, I thought I had just lost my job and also I would now have to pay all the losses out of my pocket but fortunately I didn't have to cause no transactions​ had yet been made. After that I always checked my integrations atleast five times before publishing. The incident scared the shit out of me but taught me the value of developer responsibility.

Client: i want payment integration without using any of those 3rd party gateways like 2checkout.

Me: uhmmm, any reason you cant use those gateways?

Client: its more professional

...

they also take percentages on every transaction !

Me: ... *closes chat*

This guy is soo obsessed with bricks

Payment gateways are such a big pain to implement. Docs say that they will return values A,B,C but what you end up recieving is X,Y,Z.
And don't get me started on the webhooks, man they return values completely different values from the api end points and with no reference what so ever to the fields returned by them.

Wish i could get the documentation writer's address and may be the dev as well!!

Payment gateways are a fucking pain in the ass...

According to my colleagues who have to deal with it 🤣.

One is about to break, begging everyone subscribe to his service.

When you think everything is fine and you can enjoy your holiday, but then your boss opens a ticket that customers lose money someone buys their product.

Fuck payment gateways for sending a formatted string instead of a unified integer

Urrrgghhh! Payment Gateways. Why can't they be a simple as Stripe. 😥

Am I in developer hell already? A shitty project is about to come to an end (hopefully), or should I rather say: It needs to come to an end. But I am still quite lost in how to deal with it, hence procrastinating on it - making the deadline come closer and with it the realization that I'll probably have to rewrite almost everything. I'm not sure how, but I do know that the current code is a dumpster fire.

Basically what I need to do is dealing with the APIs of different payment providers/gateways (like PayPal, AmazonPay). For most cases I'll get a payment ID from the shop and need to act on it later, e.g. capture the authorized money in the case of a credit card transaction or do refunds (without user interaction, unless there is an error). Now at first I put something together where I try to abstract the payment information into two tables:
orders{1}<->{0..n}payments
payments{1}<->{1..n}paymentDetails

Unfortunately trying to abstract the different payment methods and to squeeze them (and their different possible stati and functions) in these tables was not very successful, it's a total mess with magic numbers, half-broken behavior and without any consideration for partial payments/captures or unfinished requests (i.e. if there is an exception before the response is dealt with, there is no indication that anything has ever been sent). Also the current amount is calculated through the history of the paymentDetails table, which basically works differently for each payment type.

How to fix this mess in a way that I'll still have a job by next week?

I'm trying to improve the db schema first, as I think my biggest problems are lying there. Through some research I've come across a recommendation for making payment type specific subtables (with a magic number/string in the main table to prevent having to look up all subtables). That way I can record what I send and receive without having to abstract it too much, so I'll have an acceptable transaction log. The paymentDetails table can be removed (necessary fields go to the payments table). The payments table gets multiple fields for the amount (differentiating between open, authorized, captured, processing and refunded values) and always reflects the current status.

Tables:
payments
paymentRequestsPaypal
paymentRequestsAmazonpay
paymentRequestsXyz

I think I'm going in the right direction here. hm. Maybe there's some light at the end of this long, dark tunnel. Or a train. I'll have two days to find out.

Very reassuring when your payment gateways XML examples have invalid markup.
I asked for XSD's and even they are invalid (containing missing type references)

working on simple crud is hell of boring thing now, gimme more challenges SoS, apis, payment gateways stuff...I need them like narcos

I used to write many payment gateways integrations, so I had to work with many poorly written docs.
I didn't like Robokassa, QuickPay and Payza
On the other hand, I liked PayPal because of ease and clarity, Authorize.net, Stripe

Does anyone here have experience with the eBay iOS or Android app, specifically with setting up alternate payment gateways on eBay (other than PayPal) to collect payment on purchased items? I have a client who for various reasons can no longer use PayPal to collect payment on eBay. On purchases made via the website on Desktop there are no problems with Authorize.net. But when people try to purchase via the app specifically, they are given a stupid and unhelpful message to use the desktop browser purchase experience instead. For the client it is costing about 60% of potential eBay sales.

Everything I’ve been reading on eBay’s own forums and elsewhere shows that this is an ongoing and unsolved issue for a lot of store owners and eBay seems to be in no hurry to remedy it. I’ve been over this several times with multiple eBay support reps but all I get are inconsistent and misleading answers. Or maybe I’m just not asking or searching right and the answer is out there somewhere. Any advice?