Taking cards locally is mostly paperwork and one careful integration. Here's the map.
If you're selling in North Macedonia, accepting local cards through Casys CPay is often the single biggest conversion unlock available to you. Local shoppers expect to pay with the card in their pocket, and every extra hoop between them and that card costs you orders. It's also the step that intimidates people the most, because it pulls together your bank, a payment gateway, and some security requirements all at once. Let me lay out how the pieces actually fit, so it stops feeling like a black box.
The first thing to understand is that most of the work here isn't technical at all. It's procedural — agreements and credentials — and that's the part you should start early, because it's reliably the slowest. The actual integration, once you have what you need, is quick and well-trodden. People get this backwards, rush the paperwork, and then sit waiting on the bank while their launch date slips.
What you'll need before you start
Gather these before you write a line of configuration. Having them in hand turns a stressful, blocked launch into a smooth afternoon.
- A merchant agreement with your acquiring bank for online card acceptance.
- Your CPay gateway credentials and the details for the test environment.
- 3-D Secure enabled — it's both a security requirement and a chargeback shield.
- Clear refund and dispute processes, agreed with your bank in advance.
- A full test-card flow you run end to end before you ever flip it live.
The one rule that prevents most disasters
Here's the golden rule of any card integration, and it applies to CPay exactly as much as to any global processor: a payment is real only when the gateway says so, never when the browser redirects back to your thank-you page. The customer's browser can close, lose signal, or be interfered with in the seconds between paying and landing back on your site. If you mark the order paid based on that redirect, you're building on sand.
Instead, mark orders paid on the verified confirmation from the gateway. Handle the 3-D Secure step cleanly — it's an extra hop where the customer authenticates with their bank — and treat the browser redirect purely as a convenience for showing a nice confirmation screen. The money's status is the gateway's truth, not the browser's.
“A card payment is real when the gateway confirms it — not when the customer's browser says thanks.”
Test the unhappy paths on purpose
Everyone tests the happy path: enter a good card, get a successful order, celebrate. Almost nobody deliberately tests the ugly ones — and the ugly ones are where real customers live. Before you go live, intentionally fail a payment with a declined card. Start a 3-D Secure challenge and abandon it halfway. Double-submit an order by mashing the button. The way your store behaves in those exact moments is the difference between a clean checkout and a steady stream of confused support emails.
Pay special attention to the 'pending' state — a payment that's neither clearly succeeded nor clearly failed. This is where duplicate charges and phantom orders are born. Decide in advance how your store treats a pending payment, and test that it does what you decided.
What Vendor handles for you
We built the CPay flow so the careful parts are built in rather than left for you to get exactly right under deadline pressure. Gateway confirmations, the 3-D Secure hop, and idempotent order updates — so a retry never double-charges — are handled by the platform. Your job shrinks to the part that's genuinely yours: getting the agreement with your bank and deciding your refund policy. The fiddly, high-stakes plumbing is ours.
