A merchant setting up card payments for the first time usually pictures a single button: the customer clicks, the money arrives. Behind that button several parties hold a short conversation, checking each other, and all of it takes a couple of seconds. The flow is worth understanding — not because you will write the code, but because the decisions you make as a shop owner depend on it: what happens when a payment fails, when the money is actually taken and how it goes back.
Every card transaction involves a handful of parties. The customer, with a card and the bank that issued it. The merchant, with a website and a bank that granted an agreement for online card acceptance. Between them sits the gateway — the technical intermediary that receives the card data, protects it and passes it on — and the card network, which routes the message to the right bank and back. In Montenegro that work is done by domestic banks and by gateway solutions already operating on this market; which one you end up with depends on your bank and on what you sell.
The flow goes like this. The customer confirms an order on your site and moves to payment. At that point the system either redirects them to a secure page for entering card details or shows such a page within your site — but the card data does not pass through your server and is not stored with you. That is not a technical footnote: it dramatically reduces your responsibility for that data. The request then travels to the bank that issued the card, which checks whether the card is valid, whether funds are available and whether the transaction looks ordinary.
The step customers notice most is called 3D Secure. Here the customer’s own bank asks for confirmation that the person paying is really them — usually through its app or a message on the phone. That is why the customer is taken to the bank’s page for a moment and then brought back. This step is not an obstacle to be worked around: it shifts liability for a disputed transaction from the merchant to the card issuer, and it is the standard in online sales. Your job is to prepare the customer — to make it clear at checkout that a confirmation is coming, because a share of abandoned payments happens right there, at an unexpected screen.
Card data should never touch your server. What you never stored is something you cannot lose.
The next distinction matters and is rarely explained: authorisation is not the same as capture. An authorisation means the bank approves the amount and reserves it on the card, but the money has not moved yet. Capture is the separate step that actually takes the approved amount. For a shop that ships immediately the two usually happen together. For reservations, deposits and orders waiting on availability, splitting them is exactly what you want: the amount is reserved and charged only once the service is confirmed. A refund travels the same route in reverse and takes its own time, because it passes through the same parties.
In practice most of the trouble comes not from the successful payment but from the failed one. The system has to tell apart a declined payment, a customer who walked away, and a case where no answer arrived — those are not the same situation. In every case the customer needs a clear message and a way to try again, and the order must not be left in an undefined state. Equally, two clicks on the same button must not create two charges, and a repeated confirmation from the bank must not duplicate an order. None of this shows in a demo, but all of it is felt on the first weekend with nobody around to fix things by hand.
Card payments aren’t tested with the happy path — they’re tested by what happens when something breaks halfway through.
So what do you, as the merchant, actually need. First, an agreement with a bank for online card acceptance — the bank will look at what you sell and how you operate. Second, a gateway integration on the site, with secure transport of the data. Third, invoice fiscalisation in order, because selling online does not exempt you from the obligations you already have at the till. And fourth, the part most often forgotten: clearly written terms of sale, delivery, cancellation and complaints, plus a contact where a customer can actually reach you. That is not paperwork — it is part of the trust that decides whether anyone types in a card number.
All of which is why payment belongs at the start of a project rather than as the last item before launch. The paperwork with the bank has its own pace, the integration is first built in a test environment, and test transactions are taken all the way through — including a decline and a refund. Projects that leave payments for the end usually stall exactly there, at the moment when waiting is most expensive.
What it looks like when everything is connected is easiest to describe with an example: for the national railway company of Montenegro we built a system where a passenger buys a train ticket online, pays by card and receives the ticket by email, with no trip to the counter. The same approach powers shops, bookings and deposits. The integration itself is described on the online payment integration page, and the order of steps before opening a shop is covered in our article on online payments in Montenegro.
If one thing is worth remembering, it is this: card payment is a process, not a button. Set up in the right order, it looks to the customer like a couple of seconds of silence and a message that everything went through — and that impression is why they come back.