The dynamic pricing features you to serve any price offer or promotion to any customer.
If you implement it you can skip the parts listed below:
- Trigger the payment selection screen
- Trigger Dynamic Promotions
- Set up the packages and the prices
- Set up promotions
The dynamic pricing feature enables the following:
- You can make personalized offers (on a per user/cohort/user level/whatever basis you want)
- You can sell individual items (by showing only one package in the payment screen)
- You can offer and optimize your in-game shop and only use the Spil payment screen as a check-out (whereby the package that the user selected in the game shop is the only visible package)
- You do not have to maintain prices in the Spil Games payments back-end
The dynamic pricing process flow works as follows:
- You invoke the Spil Games payment screen from your front-end and specify that dynamic pricing is applied.
- The Spil payments back-end will post information to your back-end at the url you have provided as verification url (not to be confused with Notification/callback url) in order to retrieve package data. You have to set both on your game page at our payment-admin tool. See more here.
- If we receive an json formatted file as a reply from your side we will trigger the payment screen with the package information indicated by the json file.
1. Invoking the payment screen using dynamic pricing:
The method in the example below takes an object as its first and only argument. The object is a simple key-value representation of the parameters used to determine the content of the payment selection screen. Please note that the custom parameters have a limit of 200 characters.
2. Receiving information from Spil Games
If this completes successfully then the Spil Games payments back-end will post a message to your back-end using the verification url (not to be confused with Notification/callback url) that was registered by you in the Spil Games payments admin tool, on the game configuration page.
Note: If you haven’t set the verification URL you won’t receive anything from our side.
The format of this message is as follows:
|In this case you will receive as method name: “pricing”|
|This is unique identifier of our user. For more information about GUID look here.|
|The country code (alpha 2) defined by the user’s geolocation (http://en.wikipedia.org/wiki/ISO_3166-1).|
|The 3-character currency code defined by the user’s geolocation (http://en.wikipedia.org/wiki/ISO_4217)|
|The custom parameters that you sent when you invoked the payment screen.|
|We generate a SHA-256 hash based on your payment secret and the parameters above, concatenated in one single string (secret+method+guid+country_code+currency+custom_parameters).|
3. Returning pricing information in json
If we receive a JSON formatted file (as below) from you after this, we will trigger a payment screen with the package and price information you specified and the users are able to purchase a package from the information you specified.
IMPORTANT: The json should contain prices on Euros or User’s currency!!!
For example, if the user located in Denmark you can either
- send the prices in DKK and the user will directly see the prices you sent to us or
- send the prices in EUR, we convert to DKK and display them to the user.
Here is the explanation of all the properties of the json file:
|currency||String||Yes||Currency code of the packages. If your currency doesn’t match the user currency we will make the conversion for you. The conversion feature can be useful in case of exotic currencies for which you don’t want to maintain separate configurations.|
|sku_types||Yes||They SKU types that you offer, you should have at least 1.|
|sku_type_default_text||String||Yes||The default name of your SKU type (e.g. Rubies, Coins, Cash, Pearls, etc)|
|sky_type_translated_text||String||Yes||Translated text of this SKU type. You can use the English text in case you don’t want to translate the name.|
|sku_type_image||String||Yes||Image used for the SKU type in our payment screen. For performance reasons, the image has to be 30×25 px and a maximum of 7KB.|
|packages||Yes||Group of packages, you should have at least 1 package.|
|amount||Numeric||Yes||Price amount of this package in the currency mentioned above.|
|sku_unit||Integer||Yes||Unit number of this SKU type.|
Calculates the extra SKU amount you assign to the promotion. It accepts numeric values:
|package_image||String||Yes||Image used for the package in our payment screen. For performance reasons, the image has to be 90×45 px and maximum of 7KB.|
|external_id||String||No||Optional value to pass customized identifier to payment backend. This value will appear in custom parameters (custom_parameters) of the callback notification.
You can use that if you want to attach a specific param to a package but you don’t have the ability to do that from the front-end on step 1 when you invoke our payments screen.