A voice AI agent for inbound and outbound calls: available 24/7, follows business workflows, performs actions in connec…
A practical guide to CRM–ERP integration: data to synchronise, sources of truth, APIs and webhooks, duplicate protectio…
Adding a Pay button is not the job. The job is that a decline does not lose the order, a refund goes through without the accountant, and the money in the account matches the sales in the system.
Discuss the integrationThe amount is fixedThe order is created before payment, so it exists even if the payment fails
Handover to the gatewayCard details are entered on the bank's side — they never reach your server
Bank confirmation3-D Secure: the cardholder confirms the operation in their own bank's app
The gateway respondsSuccess or decline arrives both on the page and as a separate notification, in case the customer closed the tab
The order updatesThe status changes, stock is written off and the customer gets a confirmation with details
ReconciliationThe bank statement is matched to orders: what is paid, refunded or stuck is visible
We look at who your buyers are and how they pay: card, bank transfer, cash on delivery, instalments.
We prepare the technical side of the application, answer the bank's questions and go through test mode with you.
The payment form, 3-D Secure, result notifications and correct handling of a dropped connection.
A clear message to the customer, the order preserved and a link to pay another way.
Full and partial refunds from the admin panel, reflected in the order and in the books.
Matching incoming payments to orders and a report of what does not add up.
Card data never passes through your server, the connection is secured and access is split by role.
Test payments from phones and desktops, including decline and refund scenarios.
The acquiring contract is between the store and its bank: rates, fees and settlement times stay between you and them. VMTech is responsible for the technical side: integration, error handling, refunds and reconciliation.
A card acceptance contract with the bank and a working site with product descriptions, delivery and refund terms — the bank checks those. We prepare the technical side and go through test mode with you; the bank's approval usually takes longer than the development.
No, and that is deliberate. Details are entered on the bank's secure page and never reach your server — you receive only the transaction result and its identifier. That removes the obligations that come with storing card data.
It happens when the site only learns about a payment from the customer returning to the page. We connect a separate gateway notification to the server: even if the customer closed the tab or lost connection, the order status updates. There is also a periodic check for stuck payments.
Yes, and on the Serbian market it is often the main method. The difference is that the money arrives from the carrier later, so those orders follow their own chain of statuses and reconciliation runs against the carrier's report rather than the bank statement.
From the admin panel: a full or partial refund against a specific transaction. The system sends the request to the gateway, stores the result and updates the order status. The accountant sees the refund in a report rather than learning of it from a customer email a month later.
