How to accept card payments online in Bosnia and Herzegovina and Serbia

Why Stripe and Shopify Payments are not an option

Stripe's list of countries where businesses can sign up includes Croatia and Slovenia, but not Bosnia and Herzegovina, Serbia, Montenegro or North Macedonia (Stripe, global availability). Shopify Payments has the same gap: its list of supported countries includes Croatia, not Bosnia and Herzegovina or Serbia, and Shopify tells merchants outside that list to use a third-party payment provider (Shopify Help Center).

Opening a company abroad only to use these services is sometimes suggested online. That creates a separate company with its own legal and tax obligations, and it is outside the scope of this guide.

The two parts of a local setup

A contract with a bank to accept cards online. The bank accepts the card payments made in your web shop and pays them out to your business account. In Serbia this is a contract for accepting payment cards at an internet point of sale (UniCredit Bank Srbija, e-commerce conditions). Banks in Bosnia and Herzegovina offer the same kind of service to web shops, for example Raiffeisen Bank's e-pay (Raiffeisen Bank BiH, e-pay).

A payment gateway. This is the technical service that shows the payment form, passes the card details to the bank and returns the result to your website. Some gateways are independent companies, such as Monri or CorvusPay. Some banks run their own virtual POS, for example on Payten's NestPay platform, in which case the connection details depend on the bank (NestPay plugin documentation).

Depending on the provider, you sign with the bank and the gateway separately, or the gateway arranges the bank side for you. Ask each provider which applies before you compare offers.

Step by step

1. Registered business and business account. Card acceptance contracts are signed by businesses, so the company and its account at the bank come first.
2. A website ready for review. Before going live, expect your bank or gateway to look at the web shop. Have your company details, prices, terms of sale, delivery and refund rules and privacy policy published, and ask the provider for its own checklist, including which card and security logos it wants shown.
3. Choose how payments connect. The main options are a hosted payment page or payment link, a payment form embedded in your page, or a direct API connection. Ready-made plugins exist for common shop platforms, for example CorvusPay for Adobe Commerce (Adobe Commerce Marketplace). The choice decides how much of the security standard applies to you, explained below.
4. Test before going live. Run successful, declined and 3-D Secure payments in the provider's test environment, and check that your shop records each result correctly.
5. Go live and keep it running. Plan who handles refunds and disputed payments, how payouts are matched to orders, and who keeps the plugin or integration up to date.

3-D Secure: the extra confirmation step

3-D Secure asks the cardholder to confirm an online payment with their bank, for example with a one-time code. The card schemes run it under their own names: Visa Secure, Mastercard Identity Check and American Express SafeKey.

In Serbia, DinaCard now has its own 3-D Secure. It was introduced at the initiative of the National Bank of Serbia, with Banka Poštanska štedionica, ALTA Banka and OTP Banka Srbija live first (ASEE, June 2026). If you sell to customers in Serbia, ask your provider whether DinaCard payments are enabled for your shop (Kurir Biznis).

PCI DSS in plain words

PCI DSS is the card industry's security standard for anyone who accepts card payments. Your bank tells you how to show that you comply. For a small web shop this is usually a self-assessment questionnaire (SAQ), and which one applies depends on how the payment form is connected.

• Hosted payment page, payment link or embedded provider form: card details never touch your server, which is what the shortest questionnaire, SAQ A, is for.
• Your own page collects or handles the card details: the longer SAQ A-EP or SAQ D applies.

SAQ A changed in 2025. The January 2025 revision, in effect from 31 March 2025, removed requirements 6.4.3, 11.6.1 and 12.3.1 and added a condition: the merchant confirms its site is not susceptible to attacks from scripts that could affect its e-commerce systems. According to PCI guidance summarized by security firms, that condition concerns sites with an embedded payment form, not redirects or payment links (Akamai; AccessIT Group). Confirm the questionnaire with your bank.

Questions to ask a bank or gateway

• Which cards can my customers use: Visa, Mastercard, Maestro, American Express, DinaCard?
• Do I sign with the bank, with you, or with both?
• What are the setup, monthly and per-transaction fees?
• In which currency are payments settled, and how soon are they paid out?
• Can customers pay in installments?
• Which connection types and plugins do you offer for my shop platform, and is there a test environment?
• Which PCI DSS questionnaire applies to my setup?
• Who do I call when a payment fails, and when is support available?

Where ZIMS Development fits

ZIMS Development handles the integration with established payment providers and stays on hand with support once payments are live. If you want help choosing a provider or connecting it to your website, book a free consultation or read about our online payment integration service.

This guide is general information, not legal or financial advice. Provider terms change: confirm the details with your bank and payment provider.