USD Payments and Security Updates in Zeneva

Two updates, and what each actually changes

This post covers multi-currency support and the security model. Both get described in vague superlatives across this industry, so it is worth being specific about where each one's usefulness starts and stops.

---

1. Pricing and taking payment in USD

The gap this closes is real. A Nigerian vendor selling to a relative in London or a customer in New York has historically had a workflow that ends in an awkward conversation about exchange rates and a screenshot of a transfer.

What Zeneva provides: the ability to price, sell and report in USD alongside naira, so receipts, reports and stock valuations are internally consistent rather than converted by hand at whatever rate someone remembered.

What Paystack provides: the actual payment rails — international card acceptance, conversion, and settlement.

That division matters more than it might sound. Whether a specific card from a specific country will go through, what rate applies, and what account foreign-currency settlement can land in are all determined by your Paystack account and its verification status, not by us. We cannot promise on their behalf, and any vendor who does is guessing.

Before you announce it to customers

1. Connect Paystack and confirm your business account is verified, including for international transactions specifically. Domestic verification is not the same thing.
2. Run one real transaction for a small amount. Not a test-mode transaction — a real one.
3. Confirm where the money lands, and how long it took. This is the step people skip, and it is the only one that answers the question that matters.
4. Then tell customers you accept international payments.

The cost of that sequence is a few hundred naira in fees and an afternoon. The cost of skipping it is telling a customer abroad that you accept their card and finding out at the point of sale that you do not.

---

2. What the encryption does, precisely

Data at rest is encrypted with AES-256; data in transit uses standard TLS. Those are the right choices and they are table stakes rather than a differentiator — any serious hosted product does the same.

What is worth being precise about is the threat each addresses:

• Encryption at rest protects your records if storage media are compromised. Without the keys, the data is unreadable.
• TLS in transit protects the connection between your device and the servers.

And what neither addresses: anyone holding a valid login. Encryption is indifferent to who is typing. It is a good control against a category of attack that is not, for most Nigerian retailers, the category actually costing them money.

We mention this because "bank-grade encryption" is frequently sold as though it answers the question owners are really asking, which is usually about the counter rather than about the server.

---

3. The controls that address real retail losses

Retail loss is overwhelmingly a permissions and attribution problem, not a cryptography problem. Three things do the work:

Granular roles. Counter staff should be able to sell and nothing else. They do not need analytics, cost prices, or the ability to change a price. Restricting this is a five-minute setting that removes whole categories of problem, and most shops never open it.

One login per person. The precondition for everything else. A shop where three cashiers share one account has an audit log full of actions attributed to nobody — you will know a void happened at 14:32 and you will never know who did it. Shared logins silently disable every accountability feature in the product at once.

Audit alerting. The system flags patterns in your own log: accounts voiding more than the store average, repeated price overrides on the same products, unusual stock adjustments, permission changes.

A flag is a prompt to look, not a conclusion. The cashier voiding most often may be the one handling returns. Treating a pattern alert as an accusation is how owners lose good staff over a report they did not read carefully. Preventing retail theft with audit logs covers how to investigate one properly.

---

4. What we do not claim

A short section because these claims are common and mostly not true.

• We do not claim our staff can never access data. Access is restricted by role and logged. Support work occasionally requires it. Any hosted product asserting literal impossibility is overstating what hosting permits.
• We do not claim encryption stops theft. It stops a different problem. See above.
• We do not promise specific uptime numbers without an SLA behind them, and we do not have one on the free tier.
• We do not promise international cards will work for your specific customer. That depends on Paystack, the issuing bank and your verification status.

Each of those is a claim we could make and that would look better on this page. They are omitted because a claim you find out is untrue at the worst moment costs more trust than it ever bought.

---

What to do this week

If you read one section, read this one — it is the part with an action attached.

1. Give every staff member their own login. Half an hour. Nothing else in this post works without it.
2. Restrict counter roles to selling. Five minutes.
3. Put ten minutes in your calendar weekly to look at voids and price overrides by staff member. Not the full log — you will stop within a fortnight. The exceptions only.
4. If you want USD: connect Paystack, verify, run one real transaction, confirm settlement. Then announce it.

Items 1 to 3 cost nothing and address where the money actually goes. Item 4 opens a market that was previously closed to you.

For the wider setup sequence see getting started with Zeneva, and if capital rather than tooling is your constraint, the business grants directory lists verified schemes for Nigerian SMEs. Plan details are on the pricing page.