Payment button on a website in Morocco: four ways to get paid without an online store

A payment button on a website in Morocco does not require an online store: it is a plain link to a payment page hosted by ChariPay, which you can place on any page: a WordPress site without WooCommerce, a website builder page or a landing page. Four options exist: a button pointing to a reusable payment link, at a fixed price, created through the API; a form, after which your server creates a payment link or session for the exact amount; a hosted product page, with no developer; or, once the site becomes a real store, WooCommerce or Shopify. This guide covers each one, then what to write around the button and how to know who paid.

A payment button on a website, without a store: how it works

ChariPay is a Moroccan payment platform, a PSP operated by Chari Money, a payment institution licensed by Bank Al-Maghrib. A payment button with ChariPay is deliberately simple: the button is just a link. When visitors click, they leave your page for a payment page hosted by ChariPay, enter their card, confirm with their bank through 3-D Secure, and the amount lands in your payment account.

The practical consequence: the button works on any site that accepts a link. A WordPress showcase site without WooCommerce, a page made with a website builder, a campaign landing page, a mini-site for an event: all you need is the ability to create a button and give it an address. There is nothing to install and no code to paste into the page; each website builder's own payment features are not the topic here.

What changes from one option to the next is how the address behind the button is created: once and for all, or for each visitor.

Option 1: a button pointing to a reusable payment link

This is the fixed-price option, with a single API call made once and for all. A payment link is an amount and a description; the customer pays on a page hosted by ChariPay. It is single-use or reusable, with an expiry of your choice — 24 hours, 7 days, 30 days, never, or an exact date — and a clear status: active, paid, canceled, expired. For a button, you need a reusable link: the same address serves every visitor, at the same price. From the portal, every payment link you create is single-use. The reusable link — one amount paid by several customers — is created through the API, with singleUse: false; once created, it shows up in the portal like the others. The payment page can be customized from your account settings, with your name and logo.

1. 1Create the link once, through the API: POST /v1/payment-links with singleUse: false, a fixed amount, a clear description ("45-minute consultation", "Annual membership") and, if the offer has an end, an expiry date (expiresAt); the full call, in its single-use version, is shown in option 2.
2. 2Copy its address: the payUrl returned at creation.
3. 3Paste it as the button's target in your website editor, and give the button an explicit label.
4. 4Test it: click the button, check the page that opens, the amount and the description.

Typical uses: a single price (a consultation, a workshop, an entry fee), a fixed-amount membership, a coaching session. A personal trainer in Tangier, for example, can put "Book and pay for my session" under the price list. One rule to remember: a reusable link only collects cards; cash goes through a single-use link, one reference per deposit. Without a developer, to sell several times at the same price, publish a product on your hosted storefront and share its link: that is option 3.

The full offer is on the payment links page, and every field of a link is covered in the guide to creating a payment link.

Try it right now on a staging page: Start in test mode. Three fields (name, work email, company), an activation link sent by email to choose your password, then the portal, where you create your own test key after re-authenticating; with it, you create a reusable test link, put it behind a button and pay it with the test card. It is free, with no time limit and no approval to wait for: your business verification (KYB) only gates the move to production.

Option 2: a form, and your server creates the link or session

When the amount or the customer changes every time (a quote, a booking with options, a custom order), a fixed link is no longer enough. The button then opens a short form that sends the request to your server; your server creates the payment for the right amount, then redirects the visitor to the hosted page.

Your server has two options. The first is a single-use link. One call is enough: POST /v1/payment-links returns the payUrl to share.

curl -X POST 'https://api-psp.charipay.ma/v1/payment-links' \
  -H 'X-CHARI-PAY-API-KEY: chari_sk_test_...' \
  -H 'Content-Type: application/json' \
  -H 'Idempotency-Key: order-1042-link' \
  -d '{
    "amount": 149.90,
    "description": "Commande #1042",
    "singleUse": true,
    "externalId": "order-1042",
    "customerEmail": "amine.bennani@example.com",
    "customerPhone": "+212600000000",
    "metadata": { "cartId": "c_987" }
  }'

The response (201, or 200 on replay with the same externalId) contains the link's reference (pl_…) and its payUrl, to which your server redirects the visitor. On the page of a single-use link, your customer can choose between card and cash at an agency.

The second option is a checkout session: you create the session server-side, redirect the buyer to the hosted checkout — card with 3-D Secure — and receive the result through a signed webhook. In practice, your server redirects the visitor to the checkoutUrl returned when the session is created. A session only collects cards.

Either way, the API key stays on the server, never in the page's code: a button that called the API from the browser would expose your key to every visitor. To choose between the two, read payment link or checkout.

Option 3: a hosted product page

This is the no-developer route for a fixed price, and a middle ground if you sell a few products. Publish your products on your hosted storefront and track your orders — awaiting payment, paid, shipped, delivered — from your portal. Each product has its price, its optional stock and its sales page; your button simply points to that page, and the page does the collecting. On the hosted storefront, the buyer chooses at checkout to pay by card — on the hosted payment page, with 3-D Secure — or in cash: they then receive a reference to pay at an agency of the Chari network.

The advantage over option 1 is tracking: every purchase becomes an order, which you follow in the portal through to delivery, and each product can carry a stock. A ceramics maker in Safi, for example, can point each "Buy" button on her showcase site to the hosted page for the matching piece. The step-by-step is in the guide to the hosted storefront.

Option 4: moving to WooCommerce or Shopify

At some point, the showcase site becomes a store: a growing catalog, a cart, shipping fees. What you need then is not a button but a commerce platform. There is no ChariPay extension for Shopify or WooCommerce: you send a payment link for each order, without a line of code, or connect the hosted checkout through the API for an automatic redirect.

If your site already runs on WordPress, the guide to WooCommerce in Morocco covers both setups. On Shopify, see Shopify in Morocco. Either way, the payment page remains ChariPay's hosted checkout.

Choosing your option: the comparison table

A quick read: for a fixed price, option 1 if a developer can create the link once through the API, option 3 otherwise; move to option 2 as soon as the amount depends on the customer; option 3 also suits you if you sell items with stock; consider option 4 when a cart becomes essential.

What to write on and around the button

A button that converts says exactly what will happen. Three simple rules:

• An explicit label: "Pay" followed by what is being bought and the amount in dirhams, such as "Pay for my session — MAD 149.90" rather than "Submit".
• The same description on your page and on the link: customers should find on the payment page the words they just read.
• One sentence about what comes next: "You will be redirected to a payment page hosted by ChariPay, in our name; you will confirm with your bank."

Add a line saying who operates the payment, for example: "Payment processed by ChariPay, a PSP operated by Chari Money, a payment institution licensed by Bank Al-Maghrib." Buyer trust at the moment of payment is a topic in its own right, covered in secure online payment.

Knowing who paid: the portal or a webhook

Without a developer, everything is tracked in the portal: you are notified of each payment, and each link shows its status (active, paid, canceled or expired). For a reusable link, the API also returns, through GET /v1/payment-links/{reference}, the number of payments received (useCount) and the total collected (totalCollected). A reusable link is the same for everyone: if you need to tie each payment to a specific customer, option 2 is a better fit.

With a developer, the session returns the result through a signed webhook, and your server finds the order through your metadata, echoed verbatim in the event; for a session, the event also carries your orderId. Confirm the order when the webhook arrives, never on the redirect alone: the redirect says the buyer came back, not that the payment is secured.

Finally, for cash: as soon as the network confirms the deposit, the link turns "Paid" and you are notified in the portal; on the server side, read the link's state with GET /v1/payment-links/{reference}.

Frequently asked questions

How do I add a payment button to a website?

Paste the address of a payment page hosted by ChariPay as the target of a button in your website editor. For a fixed price: a reusable payment link, created once through the API with singleUse: false, or, without a developer, the page of a product on your hosted storefront. For a variable amount, your server creates a single-use link or a checkout session for each visitor.

Do I need to install a plugin or a script?

No. The button is a plain link to a hosted payment page: there is nothing to install and no code to paste into the page. If your site becomes a store, note that there is no ChariPay extension for Shopify or WooCommerce: you send a payment link for each order, or connect the hosted checkout through the API.

Does the button work on a WordPress site without WooCommerce?

Yes. The button is just a link: it works on any page that lets you create a button and give it an address, whether WordPress without WooCommerce, a site made with a website builder or a landing page. Payment happens on the page hosted by ChariPay, and you track collections in the portal.

Can a button be used for variable amounts?

Yes, with option 2. The button opens a form that sends the request to your server; your server creates a single-use link or a checkout session for the right amount, then redirects the visitor to the payment page. The API key stays on the server. A reusable link, on the other hand, always has the same fixed amount.

Does a payment button accept cash at an agency?

Not a button pointing to a reusable link, which only collects cards, and not a checkout session either. On the link side, cash goes through a single-use link: if your server creates one for each customer, that customer can choose on the page to pay by card or in cash, with a reference to pay at an agency of the Chari network. A hosted storefront product page, for its part, lets the buyer choose cash at checkout.

Does the payment happen inside my website?

No: the visitor goes to a payment page hosted by ChariPay, in your name, and can then come back to your site. Through the API, the return URLs of a link (acceptUrl, declineUrl) or of a session bring them back to your pages. That is what keeps you away from card data: you never see a card number, and it never goes through your site.

How do I know who paid through the button?

In the portal, you are notified of every payment and each link shows its status. For a reusable link, useCount and totalCollected give the number of payments and the total; to tie each payment to a specific customer, prefer a single-use link or a checkout session created by your server, with your metadata.

Next step

Try option 1 today on a staging page: Start in test mode, create your test key and then a reusable link through the API, put it behind a button and pay it with the test card 4918 9141 0719 5005, CVV 123, any future expiry date, 3-D Secure code 555. Then move to option 2 or 3 if the amount varies or your catalog grows: the guide to creating a payment link and the one on the hosted storefront will help.