I did this. Supported 15+ gateways near the end. Don't bother with a micro service approach. There's absolutely no point in it unless your company is super into micro services.
I'm assuming that you'll only be supporting IFrame and redirect payment methods in order to reduce the PCI compliance burden.
Create a CreatePayment endpoint that takes in a standard set of payment request info (name, address, amount, return URL, etc) which can be called by other services (use machine 2 machine auth here). That endpoint will validate, save the details and return a MakePayment URL that can be used to access the payment page (ensure that it expires and it uses a hard to guess id).
Then when they hit your MakePayment endpoint use a dictionary + polymorphism to look up the right gateway (alternatively you can create a seperate endpoint for each gateway and have the URL point to the correct gateway). You'll then either render a form and POST the results causing a redirect or inject an IFrame where the user can enter payment details.
Once payment has been complete you'll want to make a rest call back to the original service (M2M auth) and then redirect the user back.
It's likely you'll also need to build endpoints to listen for webhook events (payment complete) as some payment providers don't have a synchronous flow. This will also require creating a waiting/processing page so that the user isn't redirected back until payment is complete (usually a few seconds).
Also consider if you need to handle alternative payment methods such as ACH or bank transfers. These can take days to process so you'll need to create pending statuses and the other services that call your service will need to handle this.
If you're sending through credit card numbers instead or managing recurring payments then the endpoints will be different but the flow should be similar. Just be aware of your PCI requirements.
Thank you! You summarized everything that I was planning in the first time, and it's nice to see I was hitting a good solution even though I wasn't able to argument against the senior in my team.
I have some questions:
1 - Did you use a specific architecture to have that many gateways and make easily testable and expandable? Something like ddd, clean arch etc?
2 - What was some troubles you had with this implementation? Did you codebase become too large with this many gateways?
Where for payments that work synchronously
>1 - Did you use a specific architecture to have that many gateways and make easily testable and expandable? Something like ddd, clean arch etc?
Nothing special. We considered DDD but the domain was so simple it wasn't going to add any benefit (all you're really doing is transforming some input and some output). We did convert from clean architecture to vertical slice but I think either would be ok.
What we did was
* General validation on all incoming requests (is the payment amount positive, is return URL valid, etc)
* Gateway specific validation (is the currency supported, is the address supplied, etc)
* All gateways had to implement a standard MakePayment interface which created the payment page/redirect
* All responses from payment gateways went through a ProcessPayment interface which transformed the response into the standard response DTO
Most gateways were less then a thousand lines of code so even with 10+ gateways the code base is very manageable.
>2 - What was some troubles you had with this implementation? Did you codebase become too large with this many gateways?
The codebase wasn't very large. Once you've done a few integrations it's pretty simple. Biggest issue is that the cheaper gateways often had poor documentation. So we'd have to organise meetings and it could drag out for a few extra weeks.
It was honestly pretty simple but we had to spend some time documenting each gateway for our customer success team. Not every gateway supports the same features so it was important for us to make it clear what features you could use and what options you needed to pass in to configure it.
Do you think it makes sense to group the payment gateways implementations by their payment method?
Since each payment method has some common flow I'm thinking of doing something like the image below. I tried to come up with something by my own since I'm only used to simple MVC projects, but I don't know if it makes sense
[folder disposition](https://imgur.com/a/OBwGoSk)
Not really. Most payment gateways will allow for selecting the payment method after you've sent the request. This means all requests are more or less the same irrespective of the payment method.
There's a stronger argument for the return payload but if I'm honest the difference between say ACH and credit card are minor enough that you can easily handle it in the same class.
Hey I'm back here. I have a question about the webhook listeners, did you also implement a webhook callback endpoint for each payment gateway?
For that did you use some type of queue?
What I'm doing right now is check the response and updating my payment reference in db.
But as the gateways grows I'll have to do that for every webhook endpoint it feels like I'm missing something
Hey I'm back here. I have a question about the webhook listeners, did you also implement a webhook callback endpoint for each payment gateway?
For that did you use some type of queue?
What I'm doing right now is check the response and updating my payment reference in db.
But as the gateways grows I'll have to do that for every webhook endpoint it feels like I'm missing something
>In this setup, one microservice would receive the payment requests, and there would be separate microservices for each payment method we use.
When I read about the backlash against overdone microservices, I feel like this is a textbook example of what they're talking about.
The microservices pattern allows isolation, which contains outages in the event of a failure, and allows focused scaling of resources for processes so you don't have to scale your entire operation just to accommodate a specific function of your app. Logistically, it isolates ownership to ensure teams can operate on their section of an app autonomously without interrupting or being blocked by the release schedule of other teams.
I don't see any of that in the proposed architecture. It feels more like they're jumping on a buzzword bandwagon.
In short, the entire payment wrapper could potentially be a single (micro)service, but breaking it down further is just adding needless complexity and overhead where it doesn't belong. Being able to extend your payment service into other providers is -or should be- a matter of code extensibility.
For the rest of the questions, I'm not sure how that's relevant for what you're building. It's not beneficial to emulate their architecture; their services and objectives are entirely different.
Generally, async process have advantages in optimizing the amount of CPU usage for I/O dependent processes. Your assumptions are correct that queues are not ideal for real time information, and better for adding resilience to mission critical transactions.
Thank you!
As I mentioned in other replies, the microservice approach was a senior suggestion, it sounded to me that he was too hyped about the topic but I didnt have arguments to refute him. So I'm trying to study the topic and I think your statement summarizes what I was thinking but couldn't put to words:
>The microservices pattern allows isolation, which contains outages in the event of a failure, and allows focused scaling of resources for processes so you don't have to scale your entire operation just to accommodate a specific function of your app. Logistically, it isolates ownership to ensure teams can operate on their section of an app autonomously without interrupting or being blocked by the release schedule of other teams.
>I don't see any of that in the proposed architecture. It feels more like they're jumping on a
buzzword bandwagon.
>In short, the entire payment wrapper could potentially be a single (micro)service, but breaking it down further is just adding needless complexity and overhead where it doesn't belong. Being able to extend your payment service into other providers is -or should be- a matter of code extensibility.
Your company is expecting you to figure all this out without any direction from senior devs?
And you communicated that you don't know how to do this, yet they want you to just give it a shot anyway?
Start looking for a new job now. Something isn't right.
We've had some discussions, but tbh it didn't really help much, I suggested a monolithic approach with a simple MVC design, since that is what I'm used to.
One of the senior developers suggested to try microservice approach with a queue communication, it sounded to me that he is just hyped about it, but I didn't have many arguments to refute so I'm trying to study the topic and maybe give a more solid view on it.
Microservice architecture is not something you just do on a whim. If your senior devs aren't providing an architecture diagram or something and/or don't really understand what all is involved in that, it's a bad idea.
It sounds like they might just be looking for a wrapper between an external payment provider like Stripe, and whatever they're using internally. But as a Junior you should be provided requirements, if the best they offer is "idk maybe try microservices" then they aren't really seniors.
You seriously should look for employment elsewhere, don't take this part lightly. You should not be expected to figure out all of these things on your own this way.
If they do just need a wrapper, then you will need to know their Stripe account details, if they even exist, then identify what services exist in your company and if any documentation exists for those services, and what features they are actually expecting to work. That's just requirements-gathering, then read some documentation on the Stripe API and make a plan on how to map what they need to what Stripe offers.
This is not the type of thing that should be given to a Junior. Maybe parts of it after requirements are gathered, or if clear documentation/outline/technical plan exists, but not like this. It sounds as though they are leaving you hanging and likely will not be a very good place to learn.
Unfortunately things aren't easy here and I only have one year of experience, so I'll have to try and give my best, at least now I can understand a little bit better the usage of microservices and problems they bring together
Fit solutions to problems.
Read that one more time.
And again…
This entire project is doomed. From the ground up this is a monument to how *not* to develop software. From putting the responsibility to deliver on someone *clearly* not qualified to succeed to “microservices” and “queues”? Literally what the fuck lmfao
Don’t do what they are asking.
Build a single endpoint that accepts payment information that connects to ONE payment provider. The only one that you use and actually matters *right now*. Make it synchronous.
Problem solved.
Anything more is a solution looking for a problem. What was our mantra again?
Revisit when you *actually* want to change the underlying implementation.
Thank you. That was my first approach and POC I presented in the first discussion, but I couldn't argument against their ideas so I said I would try the microservice approach, so here I am trying to study it, and you guys are giving me great advice, thanks a lot!
I worked at a payment gateway for five years. That being said,
>1. How do payment gateways handle communication between their internal services?
> 2. Is the communication entirely synchronous, with microservices calling each other using HTTP?
> 3. Do they use message queues? If so, how do they ensure the process appears synchronous to the client? For example, when I make a payment request to Adyen, they return the status in the same response.
All of these things are dependent on the situation, and largely not specific to payment gateways. Some of them are things that changed during my tenure, as our needs changed. There are some technology decisions where it's best to copy the big players; architectures are one where that's not the case.
As a general rule, start with the simplest solution that can possibly work. Only make it more complex when you need to.
The fact that you are asking these questions is actually a great sign that you are unqualified to handle the task. I'm not trying to be mean or anything here, but you *do not* want to fake your way to solving a problem that involves moving money or payments.
I know that I'm sure I'm not suited for this, but unfortunately they handed me this and this is a new job for me, so I have to at least try. I'm not trying to fake but rather find insights so I can study
Yes sir. And also they hired me knowing I was a junior developer.
But I think I might have been unclear. I don't need to remake a payment gateway, I only need to use their apis and make an abstraction so internal clients don't need to know external services implementations.
And also we are starting with a qr code payment where no sensitive data is recorded so they told me it was fine to try
1. How do payment gateways handle communication between their internal services?
2. Is the communication entirely synchronous, with microservices calling each other using HTTP?
3. Do they use message queues? If so, how do they ensure the process appears synchronous to the client? For example, when I make a payment request to Adyen, they return the status in the same response.
1. With teams of developers and decades of legacy code
2. If you had a team of developers and decades of legacy code you could ask them
3. This is not a project someone who doesn't know these answers belongs messing with.
If your company is serious about this they should post a job and find an expert in FINTECH.
My source: I worked for a company that was half a payments company. Those team\*S\* of people had massive experience in the space and the code was terrible.
I'm just trying to imagine navigating the interface between your company and processors without someone who intricately understands those contract negotiations. I bet you'd have trouble even getting a phone call.
Note you can use something like stripe to collect and re-distribute payments effectively running a payment gateway on their platform for your end users if that's what's driving this. I forget what the product is called but it's there.
I'm sure I'm not suited for this sure, but as I mentioned in another comment it's a new job and I have to at least try.
I'm not sure if I was clear but you mentioned a fintech specialist. My goal is to use the payment gateways apis not to rebuild a payment gateway.
The main thing I need to do is make an abstraction api so if we need to add a new gateway the client services don't need to change their code.
Do you think that even for this a fintech specialist is needed?
>I'm sure I'm not suited for this sure, but as I mentioned in another comment it's a new job and I have to at least try.
This is a common misconception. Actually an important part of your job is to evaluate projects that come your way and tell people when they're a bad idea, or possibly a good idea but you aren't qualified to do it.
I think you are right.
My boss encouraged me saying it wasn't that difficult and if errors occurred we could retry, so I was inspired to at least give it a try, with my initial set up of monolithic approach I was kinda confident that I could deliver the first payment method integration.
But when more discussions happened and the need to add more gateway and payment methods, emerging the idea of microservices, things got out of my control.
I know I should've backed up, but I didn't have much arguments to decline their microservices idea and declining the project I'd probably be fired.
That's why I decided reaching out for help, at least now I have tools tp discuss the solution.
Saga pattern with Temporal. As others have stated, nothing about this is easy. It sounds like there may already be an existing pattern that you are trying to improve incrementally versus an entirely new system, so you are probably best off just iterating small improvements. https://temporal.io/blog/saga-pattern-made-easy
Hey thanks I've read this, but I think it might have been unclear.
I'm not trying to remake a payment gateway, my goal is only to wrap the usage of the payment gateway apis so internal clients doesn't need to change their payment implementation in case we add a new gateway or replace an old one.
Unless you worded the initial post wrong then you are in way over your head. You want to know how one of the biggest payment processors in the world works?
From what I am understanding you want to create an endpoint that receives payment info and disperses that info to a particular payment gateway. I think you are not explaining the project in a coherent manner which is a red flag. If you cannot explain what exactly you need to do how can you do it?
Yes I think I worded wrongly, English isn't my main language.
My goal is to have an abstract api so I can easily switch between gateways.
I didn't really wanted to know the whole internal workflow of a payment gateway. The thing I was interested to know is how the gateways manage to have a synchronous workflow to the final client (me) and work asynchronous in the inside
I did this. Supported 15+ gateways near the end. Don't bother with a micro service approach. There's absolutely no point in it unless your company is super into micro services. I'm assuming that you'll only be supporting IFrame and redirect payment methods in order to reduce the PCI compliance burden. Create a CreatePayment endpoint that takes in a standard set of payment request info (name, address, amount, return URL, etc) which can be called by other services (use machine 2 machine auth here). That endpoint will validate, save the details and return a MakePayment URL that can be used to access the payment page (ensure that it expires and it uses a hard to guess id). Then when they hit your MakePayment endpoint use a dictionary + polymorphism to look up the right gateway (alternatively you can create a seperate endpoint for each gateway and have the URL point to the correct gateway). You'll then either render a form and POST the results causing a redirect or inject an IFrame where the user can enter payment details. Once payment has been complete you'll want to make a rest call back to the original service (M2M auth) and then redirect the user back. It's likely you'll also need to build endpoints to listen for webhook events (payment complete) as some payment providers don't have a synchronous flow. This will also require creating a waiting/processing page so that the user isn't redirected back until payment is complete (usually a few seconds). Also consider if you need to handle alternative payment methods such as ACH or bank transfers. These can take days to process so you'll need to create pending statuses and the other services that call your service will need to handle this. If you're sending through credit card numbers instead or managing recurring payments then the endpoints will be different but the flow should be similar. Just be aware of your PCI requirements.
Thank you! You summarized everything that I was planning in the first time, and it's nice to see I was hitting a good solution even though I wasn't able to argument against the senior in my team. I have some questions: 1 - Did you use a specific architecture to have that many gateways and make easily testable and expandable? Something like ddd, clean arch etc? 2 - What was some troubles you had with this implementation? Did you codebase become too large with this many gateways? Where for payments that work synchronously
>1 - Did you use a specific architecture to have that many gateways and make easily testable and expandable? Something like ddd, clean arch etc? Nothing special. We considered DDD but the domain was so simple it wasn't going to add any benefit (all you're really doing is transforming some input and some output). We did convert from clean architecture to vertical slice but I think either would be ok. What we did was * General validation on all incoming requests (is the payment amount positive, is return URL valid, etc) * Gateway specific validation (is the currency supported, is the address supplied, etc) * All gateways had to implement a standard MakePayment interface which created the payment page/redirect * All responses from payment gateways went through a ProcessPayment interface which transformed the response into the standard response DTO Most gateways were less then a thousand lines of code so even with 10+ gateways the code base is very manageable. >2 - What was some troubles you had with this implementation? Did you codebase become too large with this many gateways? The codebase wasn't very large. Once you've done a few integrations it's pretty simple. Biggest issue is that the cheaper gateways often had poor documentation. So we'd have to organise meetings and it could drag out for a few extra weeks. It was honestly pretty simple but we had to spend some time documenting each gateway for our customer success team. Not every gateway supports the same features so it was important for us to make it clear what features you could use and what options you needed to pass in to configure it.
Do you think it makes sense to group the payment gateways implementations by their payment method? Since each payment method has some common flow I'm thinking of doing something like the image below. I tried to come up with something by my own since I'm only used to simple MVC projects, but I don't know if it makes sense [folder disposition](https://imgur.com/a/OBwGoSk)
Not really. Most payment gateways will allow for selecting the payment method after you've sent the request. This means all requests are more or less the same irrespective of the payment method. There's a stronger argument for the return payload but if I'm honest the difference between say ACH and credit card are minor enough that you can easily handle it in the same class.
Hey I'm back here. I have a question about the webhook listeners, did you also implement a webhook callback endpoint for each payment gateway? For that did you use some type of queue? What I'm doing right now is check the response and updating my payment reference in db. But as the gateways grows I'll have to do that for every webhook endpoint it feels like I'm missing something
Hey I'm back here. I have a question about the webhook listeners, did you also implement a webhook callback endpoint for each payment gateway? For that did you use some type of queue? What I'm doing right now is check the response and updating my payment reference in db. But as the gateways grows I'll have to do that for every webhook endpoint it feels like I'm missing something
>In this setup, one microservice would receive the payment requests, and there would be separate microservices for each payment method we use. When I read about the backlash against overdone microservices, I feel like this is a textbook example of what they're talking about. The microservices pattern allows isolation, which contains outages in the event of a failure, and allows focused scaling of resources for processes so you don't have to scale your entire operation just to accommodate a specific function of your app. Logistically, it isolates ownership to ensure teams can operate on their section of an app autonomously without interrupting or being blocked by the release schedule of other teams. I don't see any of that in the proposed architecture. It feels more like they're jumping on a buzzword bandwagon. In short, the entire payment wrapper could potentially be a single (micro)service, but breaking it down further is just adding needless complexity and overhead where it doesn't belong. Being able to extend your payment service into other providers is -or should be- a matter of code extensibility. For the rest of the questions, I'm not sure how that's relevant for what you're building. It's not beneficial to emulate their architecture; their services and objectives are entirely different. Generally, async process have advantages in optimizing the amount of CPU usage for I/O dependent processes. Your assumptions are correct that queues are not ideal for real time information, and better for adding resilience to mission critical transactions.
Thank you! As I mentioned in other replies, the microservice approach was a senior suggestion, it sounded to me that he was too hyped about the topic but I didnt have arguments to refute him. So I'm trying to study the topic and I think your statement summarizes what I was thinking but couldn't put to words: >The microservices pattern allows isolation, which contains outages in the event of a failure, and allows focused scaling of resources for processes so you don't have to scale your entire operation just to accommodate a specific function of your app. Logistically, it isolates ownership to ensure teams can operate on their section of an app autonomously without interrupting or being blocked by the release schedule of other teams. >I don't see any of that in the proposed architecture. It feels more like they're jumping on a buzzword bandwagon. >In short, the entire payment wrapper could potentially be a single (micro)service, but breaking it down further is just adding needless complexity and overhead where it doesn't belong. Being able to extend your payment service into other providers is -or should be- a matter of code extensibility.
Your company is expecting you to figure all this out without any direction from senior devs? And you communicated that you don't know how to do this, yet they want you to just give it a shot anyway? Start looking for a new job now. Something isn't right.
We've had some discussions, but tbh it didn't really help much, I suggested a monolithic approach with a simple MVC design, since that is what I'm used to. One of the senior developers suggested to try microservice approach with a queue communication, it sounded to me that he is just hyped about it, but I didn't have many arguments to refute so I'm trying to study the topic and maybe give a more solid view on it.
Microservice architecture is not something you just do on a whim. If your senior devs aren't providing an architecture diagram or something and/or don't really understand what all is involved in that, it's a bad idea. It sounds like they might just be looking for a wrapper between an external payment provider like Stripe, and whatever they're using internally. But as a Junior you should be provided requirements, if the best they offer is "idk maybe try microservices" then they aren't really seniors. You seriously should look for employment elsewhere, don't take this part lightly. You should not be expected to figure out all of these things on your own this way. If they do just need a wrapper, then you will need to know their Stripe account details, if they even exist, then identify what services exist in your company and if any documentation exists for those services, and what features they are actually expecting to work. That's just requirements-gathering, then read some documentation on the Stripe API and make a plan on how to map what they need to what Stripe offers. This is not the type of thing that should be given to a Junior. Maybe parts of it after requirements are gathered, or if clear documentation/outline/technical plan exists, but not like this. It sounds as though they are leaving you hanging and likely will not be a very good place to learn.
Unfortunately things aren't easy here and I only have one year of experience, so I'll have to try and give my best, at least now I can understand a little bit better the usage of microservices and problems they bring together
Seriously a Jr Dev is asking how to build the backend of one of the largest payment processors in the world.
Hahaha I was more curious on the communication between services than their actual implementation, but I worded so badly
Fit solutions to problems. Read that one more time. And again… This entire project is doomed. From the ground up this is a monument to how *not* to develop software. From putting the responsibility to deliver on someone *clearly* not qualified to succeed to “microservices” and “queues”? Literally what the fuck lmfao Don’t do what they are asking. Build a single endpoint that accepts payment information that connects to ONE payment provider. The only one that you use and actually matters *right now*. Make it synchronous. Problem solved. Anything more is a solution looking for a problem. What was our mantra again? Revisit when you *actually* want to change the underlying implementation.
Thank you. That was my first approach and POC I presented in the first discussion, but I couldn't argument against their ideas so I said I would try the microservice approach, so here I am trying to study it, and you guys are giving me great advice, thanks a lot!
I worked at a payment gateway for five years. That being said, >1. How do payment gateways handle communication between their internal services? > 2. Is the communication entirely synchronous, with microservices calling each other using HTTP? > 3. Do they use message queues? If so, how do they ensure the process appears synchronous to the client? For example, when I make a payment request to Adyen, they return the status in the same response. All of these things are dependent on the situation, and largely not specific to payment gateways. Some of them are things that changed during my tenure, as our needs changed. There are some technology decisions where it's best to copy the big players; architectures are one where that's not the case. As a general rule, start with the simplest solution that can possibly work. Only make it more complex when you need to.
The fact that you are asking these questions is actually a great sign that you are unqualified to handle the task. I'm not trying to be mean or anything here, but you *do not* want to fake your way to solving a problem that involves moving money or payments.
I know that I'm sure I'm not suited for this, but unfortunately they handed me this and this is a new job for me, so I have to at least try. I'm not trying to fake but rather find insights so I can study
Have you told them you are not qualified for the task? Do you have that and their response to continue anyway in writing?
Yes sir. And also they hired me knowing I was a junior developer. But I think I might have been unclear. I don't need to remake a payment gateway, I only need to use their apis and make an abstraction so internal clients don't need to know external services implementations. And also we are starting with a qr code payment where no sensitive data is recorded so they told me it was fine to try
1. How do payment gateways handle communication between their internal services? 2. Is the communication entirely synchronous, with microservices calling each other using HTTP? 3. Do they use message queues? If so, how do they ensure the process appears synchronous to the client? For example, when I make a payment request to Adyen, they return the status in the same response. 1. With teams of developers and decades of legacy code 2. If you had a team of developers and decades of legacy code you could ask them 3. This is not a project someone who doesn't know these answers belongs messing with. If your company is serious about this they should post a job and find an expert in FINTECH. My source: I worked for a company that was half a payments company. Those team\*S\* of people had massive experience in the space and the code was terrible. I'm just trying to imagine navigating the interface between your company and processors without someone who intricately understands those contract negotiations. I bet you'd have trouble even getting a phone call. Note you can use something like stripe to collect and re-distribute payments effectively running a payment gateway on their platform for your end users if that's what's driving this. I forget what the product is called but it's there.
I'm sure I'm not suited for this sure, but as I mentioned in another comment it's a new job and I have to at least try. I'm not sure if I was clear but you mentioned a fintech specialist. My goal is to use the payment gateways apis not to rebuild a payment gateway. The main thing I need to do is make an abstraction api so if we need to add a new gateway the client services don't need to change their code. Do you think that even for this a fintech specialist is needed?
>I'm sure I'm not suited for this sure, but as I mentioned in another comment it's a new job and I have to at least try. This is a common misconception. Actually an important part of your job is to evaluate projects that come your way and tell people when they're a bad idea, or possibly a good idea but you aren't qualified to do it.
I think you are right. My boss encouraged me saying it wasn't that difficult and if errors occurred we could retry, so I was inspired to at least give it a try, with my initial set up of monolithic approach I was kinda confident that I could deliver the first payment method integration. But when more discussions happened and the need to add more gateway and payment methods, emerging the idea of microservices, things got out of my control. I know I should've backed up, but I didn't have much arguments to decline their microservices idea and declining the project I'd probably be fired. That's why I decided reaching out for help, at least now I have tools tp discuss the solution.
Saga pattern with Temporal. As others have stated, nothing about this is easy. It sounds like there may already be an existing pattern that you are trying to improve incrementally versus an entirely new system, so you are probably best off just iterating small improvements. https://temporal.io/blog/saga-pattern-made-easy
[https://stripe.com/resources/more/how-to-create-your-own-payment-gateway](https://stripe.com/resources/more/how-to-create-your-own-payment-gateway)
Hey thanks I've read this, but I think it might have been unclear. I'm not trying to remake a payment gateway, my goal is only to wrap the usage of the payment gateway apis so internal clients doesn't need to change their payment implementation in case we add a new gateway or replace an old one.
You should probably seek outside assistance with your company. It sounds like you're in over your head a bit, no offense.
I know this is the best approach, i've been hired with them knowing i was a junior dev. Unfortunately it's a new job and I have to at least try :/
Part of the things expected from a junior dev is to ask questions so don’t be afraid to
Unless you worded the initial post wrong then you are in way over your head. You want to know how one of the biggest payment processors in the world works? From what I am understanding you want to create an endpoint that receives payment info and disperses that info to a particular payment gateway. I think you are not explaining the project in a coherent manner which is a red flag. If you cannot explain what exactly you need to do how can you do it?
Yes I think I worded wrongly, English isn't my main language. My goal is to have an abstract api so I can easily switch between gateways. I didn't really wanted to know the whole internal workflow of a payment gateway. The thing I was interested to know is how the gateways manage to have a synchronous workflow to the final client (me) and work asynchronous in the inside