API Integration
This guide covers the technical implementation of Merso System API integration for game companies.
You can integrate Merso via web3, via web2 or using an hybrid system.
The web3 API allows you players to buy NFTs using your in-game token, while the web2 API is the recommended way if your players buy in-game items (non NFTs) and they pay using fiat. On the other hand, the hybrid model is built for those Web3 games that allow their players buy NFTs and pay them using fiat.
In every case you must modify your game UX/UI adding a button to communicate with the Merso API.
β οΈ Before Starting
Prior to integrating the Merso System API into your game, follow these preliminary steps:
When a company expresses the desire to integrate Merso into their game, we generate an API Key and a Game ID for them. These are unique identifiers for your project and should be kept confidential to prevent unauthorized access. The JWT is generated when you authenticate with the /auth endpoint and will expire every 12 hours, requiring you to re-authenticate to continue making requests.
To call the /auth endpoint, the client needs to send the following parameters in the request body:
gameIdapiKey
We provide both parameters to the companies once they decide to implement Merso in their games.
In addition, we have two different environments in order to allow you integrate the Merso Protocol safely in your system.
You will have to use one of these URLs depending on the integration phase:
Development: https://api2.dev.merso.io
Production: https://api2.merso.io
β οΈ We're using the DEVELOPMENT URL on the following examples. Please, use the PRODUCTION URL if you need.
0. Auth
Endpoint: POST /auth
Purpose: Verify API connectivity and status
Request:
Response:
Example Request Body:
π― Integration Overview
The Merso PNPL API provides three core endpoints for game integration:
/health- API health check/merso-buy-item- Purchase an item using the Merso PNPL fiat option.
π Web2 API Endpoints
1. Health Check
Endpoint: GET /health
Purpose: Verify API connectivity and status
Request:
Response:
JavaScript Example:
2. Buy item.
Endpoint: POST /merso-buy-item
Purpose: Send the fiat payment data to the player.
Request:
Parameters:
itemPrice(number): The price of the item in USD.itemId(string): item ID to purchase.itemName(string): The name of the item.playerEmail(string): User's in-game email.playerLevel(string): The level of the player in your game.playerCountry(string): Country where the player is based on.
Optional
paymentMode(string): Desired way to pay the asset. Values must be: "BNPL" or "UPFRONT". Default in case you don't want/need it to send is set as "BNPL"
Response:
We give a concrete response depending on payment mode selected:
PNPL response:
UPFRONT response:
JavaScript example:
React frontend example:
This is an example of how you can show a payment form that acts agains our Stripe account.
3. Event system
We have developed an event system that you must subscribe to. This system allows us to inform the games when an item is not paid and they must take an action.
The events we currently have:
asset.payment_failure: Triggered when a subscription is unpaid and asset will be retired from user.
To subscribe to this event you must call the following endpoint:
Endpoint: POST /set-url-webhook-asset-unpaid`
Purpose: Set the url to communicate games that an asset is unpaid after several tries.
Request:
Parameters:
url_webhook(string): The URL that will receive the event.
Response:
The webhook_secret is a unique cryptographic key for your game. It allows you to verify that webhook requests really come from us and not from a third party.
We will call your endpoint with the following JSON payload in the event of an asset is unpaid:
event (string): Event identifier, always "asset.payment_failure" for this case.
timestamp (string): ISO 8601 timestamp indicating when the event occurred.
game_id (string): The unique ID of the game related to the event.
game_name (string): The name of the game.
player_email (string): The email of the player whose asset was deleted.
item_id (string): The unique ID of the item that was deleted.
item_name (string): The name of the deleted item.
reason (string): The reason for the webhook call (e.g., payment failed multiple times).
Verification example:
This example shows how to verify our signature, so you can be sure that the requests to your endpoint are genuinely sent by us.
Note: Please, as the client, give us a response with code 200 if you receive this event and you successfully take the action we previously agreed.
Last updated