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
Every step produces something written and shared. At any moment you know what is settled and what is still open.
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.
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 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 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.
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.
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
A programme does not use every service. The first conversation keeps the ones your need actually calls for.
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
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
An earmarked programme is proven by what it refuses as much as by what it allows. The tests cover both.
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
All of this is decided before opening: four questions, four named answers.
Leaving the programme
A programme has an end, planned or brought forward. The exit conditions are written into the contract, not improvised on the day.
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.
Present your systems, your obligations and the deadlines you have to meet.
