Sending a transfer from your ChariPay payment account: beneficiaries, fees, validation, timing

Sending a transfer from your ChariPay payment account happens in the portal, in a few screens: you pick a saved beneficiary identified by their RIB, enter the amount and a reference, read the fee quote, confirm — with one or more one-time codes if you have enabled that validation — and your balance is debited immediately. The portal states that the beneficiary receives the funds within 24 business hours. The money you send is the money you collected, available the instant a payment succeeds: you pay a supplier in the morning with last night's sales, with no settlement wait. This guide walks through every step, from the first beneficiary to accounting reconciliation, using what the portal actually shows.

What a transfer from the payment account lets you do

Your ChariPay account is a payment account held by Chari Money, a payment institution licensed by Bank Al-Maghrib, with a RIB in your company's name and a downloadable PDF certificate. Every successful payment — by card or in cash at an agency — is available there instantly. A transfer is one of the ways to move that money out, alongside bill payments and telecom top-ups through the API: it sends an amount from your balance to a third party's bank account, or to your own, at any Moroccan bank.

In practice, merchants use it for three things:

• Paying a supplier with yesterday's collections, without going through the bank or waiting for a settlement.
• Paying out to your own bank account on demand, on top of or instead of the automatic overnight payout.
• Settling a one-off expense — rent, a contractor, a refund outside the card rails — from the balance you have just built up.

The payment account complements your bank; it does not replace it. Money leaves it through traceable operations, such as a transfer, a bill payment or a top-up. For the full picture — RIB, certificate, payouts — read the payment account in Morocco; for the product page, see Wallet & payouts.

You can try this whole flow before committing a single real dirham: Start in test mode. Three fields — name, work e-mail, company — then an activation link sent by e-mail to set your password; you then create your test key from the portal and make a first payment with the test card. It is free, with no time limit and no approval to wait for: the verification of your company (KYB) only gates the move to production.

Adding a beneficiary

A transfer always goes to a saved beneficiary. The portal's "Transfers" screen — "Send money to a RIB, manage your beneficiaries and track every transfer you send" — brings together the beneficiary list, the transfer history and the sending form.

1. 1Enter the beneficiary's RIB: the identifier of the Moroccan bank account that will receive the funds. Check it against a document issued by the beneficiary's bank, not a forwarded message.
2. 2Give it an alias — "Wholesaler Derb Omar", "Workshop rent" — so you can find it without re-reading twenty-four digits.
3. 3Mark it as a favorite if you pay it often: up to 5 favorite beneficiaries appear in the quick transfer on the dashboard.
4. 4Wait out the security delay before the first transfer to this new beneficiary (more on that below).

Each beneficiary then keeps its own history: every transfer sent to that RIB, with date, amount, reference and status. The transfer reference — 60 characters at most — is the text that travels with the operation: put the supplier's invoice number or the rent period in it, because that is what your accountant will look for.

The fee quote before you confirm

A transfer from the payment account carries a fixed fee per transfer. The amount is shown before confirmation, on the summary screen, alongside the amount sent: you see what will be debited from your balance before you validate, never after. We do not publish that figure on the website, because it is shown where it matters — in the portal, on every operation.

What "fixed" changes for you: the cost does not depend on the amount transferred. Grouping several invoices from the same supplier into one transfer — listing the invoice numbers in the reference — mechanically reduces fees, while splitting a payment multiplies them. The quote applies to the transfer you send; paying bills to referenced billers is debited from your balance with no additional fees, and refunding a customer remains free. The Pricing page lists what is included.

Validation with one-time codes

If you have enabled it under Settings → Security, every transfer must be confirmed with a one-time code: a 6-digit code e-mailed to each validation address you have configured. You can register several addresses — the managing director and the finance lead, for instance — and the portal then expects several codes, one per approver: the screen shows how many codes are required out of the total, and the transfer only leaves once all of them have been entered.

With several validation addresses, the person who prepares the transfer is not necessarily the one who releases it, and a compromised portal session is not enough, on its own, to move money out. Portal roles do the rest — an accountant profile reads everything, an owner or authorized profile acts, a cashier only collects, with no access to the balance or to transfers — and every action is logged with its author and date in the audit trail. The full list of controls is on the Security page.

In the sandbox, any 6-digit code is accepted: you can run the whole flow, codes included, without waiting for an e-mail.

The security delay for a new beneficiary

A beneficiary you have just added is not available right away: the portal applies a security delay after a new beneficiary is added, labeled as anti-fraud protection. The goal is simple: if someone gets into your portal, they cannot create an unknown RIB and transfer your balance to it in the same minute. The delay gives you time to spot an addition you did not make, and to react before any transfer leaves.

So that this delay never gets in the way of a due date, save your recurring suppliers as soon as you open the account, and add a new beneficiary on the day you receive its invoice rather than on the day it falls due. Beneficiaries already saved are not affected: a transfer to a favorite leaves with no particular wait.

Debit, statuses and receipt

As soon as you confirm — and enter the codes, if validation is enabled — the payment account balance is debited immediately for the amount and the fee. The transfer then appears in the history with a status:

Two practical consequences. First, an executed transfer cannot be canceled: re-read the RIB, the amount and the reference on the summary screen, because that is what commits you. Second, "within 24 business hours" is what the portal shows for receipt by the beneficiary, and it counts business hours only: weekends and public holidays are not part of it, even though your balance was debited on the spot. Keep that in mind when a due date is close.

Transfer, overnight payout or bill payment: which one to use

Three operations move money out of the payment account from the portal, and they do not serve the same purpose.

The fee quote applies to the transfer on demand; bill payment is debited from the balance with no additional fees. A simple rule: the overnight payout for what has to end up in the bank anyway, the transfer for what you decide case by case, and bill payments for referenced billers, where a transfer would be a pointless detour.

Booking and reconciling

Every transfer you send is an outgoing movement on the account, dated, with its amount, fee, reference and ID. The dashboard separates "what you collect (incoming) and what you transfer (outgoing)" and shows the available balance day by day; the CSV export carries every movement with its reference, from the portal or through the API.

To keep reconciliation a check rather than an investigation:

• Put in the reference what your accountant will search for: supplier invoice number, period, order number.
• Match each transfer to the invoice it settles, and each overnight payout to the corresponding line on your bank statement, by its reference.
• Export by period and keep the ChariPay reference on the accounting entry.

The full method — the three classic gaps between what you collect and what reaches the bank, the timezone of exports, automation — is in reconciling your collections with your accounts.

Through the API

A transfer is triggered from the portal, by an authorized person: the public API contract exposes no endpoint for sending a transfer. The Wallet module of the API documentation covers everything around the transfer: reading the balance before an outgoing operation, fetching the account's RIB to receive funds, downloading the PDF certificate, and funding the account. Four endpoints, on the single base URL https://api-psp.charipay.ma, with the key selecting the environment.

Reading the available balance, in curl:

curl -X GET 'https://api-psp.charipay.ma/v1/wallet' \
  -H 'X-CHARI-PAY-API-KEY: chari_sk_test_...'

In Node:

const response = await fetch('https://api-psp.charipay.ma/v1/wallet', {
  method: 'GET',
  headers: {
    'X-CHARI-PAY-API-KEY': process.env.CHARI_PAY_API_KEY,
  },
});

if (!response.ok) throw new Error(await response.text());
const data = await response.json(); // the balance in MAD, for the key's environment

In Python:

import os, requests

response = requests.get(
    'https://api-psp.charipay.ma/v1/wallet',
    headers={
        'X-CHARI-PAY-API-KEY': os.environ['CHARI_PAY_API_KEY'],
    },
)
response.raise_for_status()
data = response.json()

The same call doubles as an end-to-end test after you create a key: if the balance comes back, your integration is authenticated. GET /v1/wallet/account returns the account's RIB, holder and bank — to hand to a customer who pays you by transfer — and GET /v1/wallet/account/rib-document returns the certificate as a PDF. POST /v1/wallet/cash-ins, with a mandatory Idempotency-Key and an amount in MAD, funds the account when the position does not cover what you want to commit.

On the notification side, two webhook events follow the transfers you send: merchant_transfer.completed and merchant_transfer.failed, signed like all the others (X-CHARI-SIGNATURE, X-CHARI-TIMESTAMP, deduplication on Chari-Event-Id). They let you mark a supplier invoice as paid in your ERP without re-keying — see the Webhooks module. Until production is enabled, a chari_sk_live_… key receives a 403 PRODUCTION_ACCESS_NOT_ENABLED; an account whose wallet is not active answers 422 WALLET_NOT_ACTIVE.

Frequently asked questions

How much does a transfer from the payment account cost?

A fixed fee per transfer, independent of the amount, shown on the summary screen before you confirm. The figure is not published on the website: you read it in the portal, on every operation, before committing your balance. Grouping several invoices from the same supplier into one transfer lowers the total cost; paying bills to referenced billers, by contrast, carries no additional fees.

Can I cancel a transfer?

No: an executed transfer cannot be canceled, and the balance is debited as soon as you confirm. The only exception is the "Rejected" status, where the transfer was not executed and the balance has not moved. So re-read the RIB, the amount and the reference on the summary screen before entering your codes; if in doubt, the reference and transfer ID let you contact the beneficiary afterwards.

Why is my new beneficiary not available yet?

Because the portal applies a security delay after a new beneficiary is added, as anti-fraud protection: a compromised login cannot create an unknown RIB and transfer your balance to it in the same minute. Once the delay has passed, the beneficiary stays available indefinitely. Add your recurring suppliers in advance, and add a new beneficiary as soon as you receive its invoice rather than on the due date.

Who can trigger a transfer?

An owner profile, or a profile authorized to act. Portal roles separate viewing from acting: the accountant reads everything without triggering anything, the cashier only collects — no balance, no transfers, no refunds. If code validation is enabled, each configured validation address receives its own code and the transfer only leaves once all codes have been entered. Every action appears in the audit trail with its author and date.

What is the difference with the payout to my bank?

The payout is the operation that moves your balance to your bank account: automatic every night once a settlement account is configured, with a reference that appears on your statement. The transfer on demand leaves when you decide, to the beneficiary of your choice — a supplier, a third party, or your own bank outside the overnight cycle. Both come out of the same balance, available the instant a payment succeeds.

How do I get cash out of my payment account?

Through your bank: transfer to your bank account — on demand or through the overnight payout — and withdraw at your bank as usual. From the payment account itself, money leaves through traceable operations: a transfer to a Moroccan bank account, a bill payment to referenced billers, or a telecom top-up through the API.

Next step

Open your sandbox account — Start in test mode — and run a transfer end to end: add a beneficiary, read the fee quote, enter 6-digit codes, watch the "In progress" status. You will see exactly the screens your team will use in production. The Wallet & payouts page sums up everything the account can do, and the payment account in Morocco explains the framework it is held under.