Picture a traveller in a Dakar hotel room booking a tour for the next morning. She has picked a time, typed her name and pressed the button to pay. The site then sends her to another page with a different look and a different address, and asks for her card again. Many people carry on without thinking about it. Some stop to wonder whether they are still in the right place, and a few of those close the tab and go to bed.
Every business that sends customers away to pay loses a little in this way, and it rarely shows up anywhere, because people who give up halfway do not write in to complain. The surest way to stop that loss is to let the customer pay on the page they are already on. That is the job we built lomi. Payment Elements to do.
With Payment Elements, the customer pays inside your own checkout. The card fields sit in your layout, beside the basket and under your own button.
Card details
How the card fields work
Each field for the card number, the expiry date and the security code is its own frame, served from a PCI DSS compliant environment and placed in the space you leave for it. Your page draws the box. The frame fills it. You can set a light, dark or flat theme and choose the corner radius, so the frames match the page around them.
A frame like this is a separate document. Your page can show it, and it can ask it to confirm a payment, but it cannot read what was typed inside. The card number never arrives in your HTML, your JavaScript, your server, or the lomi. API. The frame will not hand you the card, so you cannot save it. There is no number for you to store.
The path from your button to a completed charge is short. Your server uses the secret key to create a card charge, in CFA francs, euros or dollars, and gets back a client secret that does not last long. Your page uses the publishable key and that secret to open the frames. The customer types into the frames. When they press your button, the page asks the frames to confirm, and the frames do. Your page is told whether it worked. Your server is told by webhook. Deliver on that signal, because a customer can close the tab or lose signal halfway through. The secret key never leaves your server.
In Safari, Apple Pay can sit above the frames on the same page, and Google Pay can do the same in Chrome. Those buttons stay Apple's and Google's. We register your domain when the frames load.
Mobile money works differently, because there is no card number to type. In Côte d'Ivoire, your server can start a Wave or MTN charge from your own checkout. With Wave, the customer approves the payment in the Wave app on their phone; with MTN, they confirm a prompt with their PIN. Until they do, the payment is pending, and your page should say so rather than announce success.
Payment Elements suits teams who already have a site or an app and care how their checkout feels, such as a software company with its own sign-up flow or a ticketing site with a seat map. It works in native iOS and Android apps too, through our React Native SDK. If you would rather not build a payment screen at all, hosted checkout is still the quickest start, and our embedded widget can show that same checkout inside your page.
To try it, create test keys in the dashboard and follow the Payment Elements guide in our documentation. The sandbox accepts test cards, so you can watch the whole flow on your own page before a real customer does.
lomi. is payment infrastructure for francophone West Africa. Accept payments, send payouts, and automate financial workflows with ease. To learn more about what drives our product roadmap, read our blog, visit our GitHub, connect your AI agent to our services, or just create an account.