Serbia E-commerce & Payments
When orders arrive but the payment step keeps failing, we follow the chain end to end.
For money to reach your account, the virtual POS, the card verification step, the currency setting and the shop plugin all have to agree. When one link breaks, the order stops at the last screen and nobody explains why. We walk the chain in order, find where it breaks, and say plainly which parts are the bank's decision and not ours.
Does any of this sound familiar?
- Customers reach the payment page, then the order disappears and nothing arrives in the bank account.
- Cards from some banks go through, cards from other banks are declined, and I see no pattern in it.
- The bank sent me the virtual POS details weeks ago and I still do not know what to do with them.
- Buyers tell me a code screen appeared, they entered the code, and the payment still did not complete.
- My prices show in euros but I need to charge in dinars, and the totals come out wrong at checkout.
- I want an IPS QR code on my invoices and order page, but I do not know how it is generated.
What this covers
Checkout diagnosis
We follow one real order through your shop, from the cart to the bank's response, and record the exact point where it stops. You get the finding in plain language, not a log dump.
Bank virtual POS setup
We connect the e-commerce acquiring details your Serbian bank issued to your shop software, including return and callback addresses. Whether the account is approved at all remains the bank's decision.
3-D Secure step-up
We look at why the extra card verification step loses customers: blocked redirects, expired sessions, mobile browsers that never come back to your site.
RSD pricing and currency
We set dinar prices, rounding and currency display so the figure the customer sees matches the figure the bank charges. Wording and tax figures come from your accountant.
IPS QR and instant transfer
We add NBS IPS QR codes and IPS deep links to your invoices and order pages so a customer can pay by instant transfer from their banking app.
How we work through it
- 1
Intake and diagnosis
You describe what the customer sees and what you see in the admin panel. We reproduce the failed checkout ourselves, in the bank's or provider's test mode wherever one is available.
- 2
Mapping the chain
We write down every part between the pay button and the bank: shop platform, payment plugin, payment service provider, acquiring bank. Then we check each link against its own logs.
- 3
Configuration and repair
We correct plugin settings, currency handling, return URLs and callback addresses, and clear whatever is blocking the handover between your site and the payment page.
- 4
Merchant test payments
You run small test payments on your own card and your own account. We watch the order records and the provider response codes while you do it, and adjust what the codes point to.
- 5
Handover and monitoring
We document the working setup, show whoever manages your shop how to read a failed order, and agree what should be checked after platform or plugin updates.
What we may ask you for
- The e-commerce onboarding documents or emails from your bank, with account numbers masked.
- Your merchant and terminal identifiers from the virtual POS paperwork. Never the secret key or a panel password.
- A screenshot of a failed order in your shop admin, showing the order number, the date and the error text.
- What the customer saw on screen and the approximate time, so we can match it against the payment log.
- A bank receipt or statement line for a test payment, with the card number and any personal identity number such as JMBG masked.
What we do not do
- We do not decide whether your business is accepted for card payments. Your bank and the payment service provider approve that under their own rules, and we will tell you when the answer sits with them.
- We do not give tax, accounting or legal advice on invoicing, VAT or fiscal receipts. We use the figures and wording your accountant confirms, and hand that part back to them.
- We never ask for full card numbers, CVV codes, one-time passwords or your bank login. Test payments are made by you, on your own card, in your own account.
- We do not build workarounds for platform or bank rules, such as routing your sales through somebody else's merchant account or a second profile to get around a restriction.
Typical milestones
- 1.Intake received
- 2.Failure reproduced
- 3.Payment chain mapped
- 4.Test payments run
- 5.Handover complete
An indication of the steps a case in this category usually passes through. Not every case follows all of them.
Questions about this service
Start a case in this category
The form asks the questions specific to this problem, so we can start from something real.