2
saucyatom
21d

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.

Comments
  • 1
    📍

    I’m leaving this here for now, since my wife would kill me if I got into writing a monster reply rn.

    Question tho: what tools are you using (langs etc for the business logic, db etc) rn and do you have a say in what to use? And where will the prod workload be hosted?
  • 0
    @100110111
    It's a module for a huge monolithic ERP (= enterprise resource planning) software (our own) written in .NET (C#) with Entity Framework and MSSQL as a DB. The dev tools are primarily Visual Studio with Resharper, TFS and a bunch of in-house tools (e.g. for managing db schemas). All parts of the software are running on the customer's systems (clients, server, db, ..). As far as tools go I have the freedom to basically use whatever I like in my own responsibility, but that doesn't really help me here.

    Specific to this project: Payment providers/gateways to be used and required procedures are given by the customer as we need to replace their current ERP.
  • 0
    @saucyatom oh well, in that case my suggestions may not be helpful, as it seems it may not be possible for you to go down that route. Tbh, this is one of the use cases where NoSQL (more specifically a document database like Mongo) could really become handy. I’m not saying you should kill the relational one completely, but it could’ve been beneficial to store there only the necessary common information (id, state, whatnot) and keep the provider specific and more fluid stuff in the document database.

    You could still benefit from driving your code toward event-driven design (saying this not knowing where it at atm), which thanks to using a relatively benign languge should be half a breeze (tho god damn, since it’s an own module, dealing with payments would’ve been ideal grounds for some F#)

    I hoped I could be more helpful than that...
  • 0
    @100110111 Thanks for your input, but going for another DB is not possible at all and neither do I have time to learn much new.. I discussed it with a senior dev and I have a rough idea how to proceed now, at least.
Add Comment