From the first conversation to a programme in service.
A programme is built with your business and technical teams. Six steps, and something written at each one. Who does what is settled before go-live. The tests also cover the payments that must be refused. The exit is planned from the outset.
Six steps
The path, from the need to the programme in service
Every step produces something written and shared. At any moment you know what is settled and what is still open.
The first conversation
Your need, the roles, the beneficiaries, the spending expected and your obligations. We also look at what you must be able to show, and to whom.
Deliverable: a shared note.
Services and interfaces
The services adopted, the payment methods, the interfaces opened to your programme and the data exchanged.
Deliverable: what is covered, settled and written down.
Who does what
Who decides the rules, who holds the funds, who enrols the beneficiaries, who receives which information, who answers users.
Deliverable: a written allocation, carried into the contract.
The tests before launch
The payments that must go through, and above all those that must be refused. Then corrections, refunds and the access rights of each role.
Deliverable: shared, signed tests.
Operation
The opening of the programme, the tracking of operations in real time, the review points and the handling of requests and incidents.
Deliverable: the programme live, on what was agreed.
Leaving the programme
You get your data back. We deal with the balances and we close the programme. All of it is written down before go-live.
Deliverable: a written exit procedure.
Services and interfaces
What MAP makes available
A programme does not use every service. The first conversation keeps the ones your need actually calls for.
- Collection
- Receipt of contributions in euros and linking to the programme funded: transfer, donation, fundraising pot, corporate giving.
- Issuance and earmarking
- Issuance of the earmarkable digital euro and setting of the programme’s rules: beneficiaries, suppliers, area, period, ceilings.
- Accounts and payments
- A real account with an IBAN, incoming and outgoing transfers, a universal payment card, online payment, the QR code and the app.
- What you see
- The views by role, the statuses in real time and the exports defined with your teams.
- White label
- Your brand at the front of the beneficiary journey. The roles of the financial operators are still shown.
What is opened
A programme only opens the interfaces it has a use for. This site publishes no sample request, no key and no service address. No interface is self-service: the applicable documentation is handed to you from the first conversation.
Who does what
What belongs to whom, written down before go-live
The roles stay distinct from one end of the programme to the other. It is that separation which makes the tracking usable.
| Subject | MAP | Your organisation |
|---|---|---|
| Funds and issuance | Issues the earmarkable digital euro up to the funds received and keeps the programme’s entries. | Pays in the funds or organises the collection, and approves the framework of use. |
| Programme rules | Implements the agreed rules and checks them before every operation. | Decides the rules and their values: who, when, how much, where and what for. |
| Beneficiaries | Opens the accounts, activates the cards and applies the programme’s list. | Decides whether a beneficiary joins the programme and keeps the list up to date. |
| Suppliers | Applies the list or the categories adopted. | Provides the list by name or the criteria, and keeps them up to date. |
| Controls | Checks 100% of operations before execution and blocks whatever falls outside the frame. | Handles the exceptions that are for it to decide and the appeals of beneficiaries. |
| Technical exchanges | Documents the interfaces opened to your programme and provides a test environment. | Carries out the development work on its side and appoints a technical lead. |
| User support | Handles what belongs to the payment service. | Handles what belongs to the programme and to the support given to people. |
The tests
Tests that also cover refusals
An earmarked programme is proven by what it refuses as much as by what it allows. The tests cover both.
The payments that must go through
- A payment at a selected supplier, by card, online and by QR code.
- A transfer from the beneficiary’s IBAN, within the authorised frame.
- The activation of an account and a card for a new beneficiary.
- The payment then showing up in each role’s view.
The payments that must be refused
- A payment outside the geographic area adopted.
- A payment outside the period, before it opens or after it ends.
- A payment above the ceiling per operation, per day or per month.
- A payment at a supplier that was not selected, and a blocked cash withdrawal.
The tests also cover corrections and refunds. When a payment is refused, the beneficiary is given the reason. And each role sees what it must see, nothing more.
Operation
Who runs the programme day to day
All of this is decided before opening: four questions, four named answers.
- Administration
- Who enrols the beneficiaries, allocates the budgets and adjusts the agreed rules.
- User requests
- Who answers a beneficiary or a supplier, and through which channel.
- What you see
- Who receives the views and the exports, how often, for which obligation.
- Incidents
- Who is called, in what order, and what is done while service is being restored.
Leaving the programme
The exit is planned before the entry
A programme has an end, planned or brought forward. The exit conditions are written into the contract, not improvised on the day.
- Your data
- What you get back, in what format and within what time frame. The contract sets it before opening.
- Treatment of balances
- What becomes of amounts left unused. An end date for use and the right to redeem the electronic money are two distinct questions.
- Closing the programme
- The closure of accounts and cards, the information given to beneficiaries and suppliers, the retention of the entries.
Scope of this page
No price and no lead time are announced on this site. What is covered, the uses, the number of users and the integration determine the commercial terms and the schedule. What is binding on you is written in the contract: see Continuity and exit, that is, leaving the programme and getting your data back.
Let us prepare the roll-out with your teams.
Present your systems, your obligations and the deadlines you have to meet. A MAP expert answers you, with no commitment.