Whenever a user completes an offer, we will make a call to the Postback URL that you indicated in your app attaching all the information that you will need to credit your users.
Our server will make a HTTP GET request to your server including the parameters that you have added. Here is the list of available macros.
Parameter | Description |
---|---|
{user_id} | This is the unique identifier code of the user who completed action on your platform. |
{reward} | The amount of your virtual currency to be credited to your user. In the case of a rejection the amount will be negative. If your Wannads account was migrated from the old system, the amount will be positive to ensure compatibility; if you wish to change it, contact your manager. |
{status} | Determines whether to add or subtract the amount of the reward. "credited" is when the virtual currency
should be added to the user and "rejected" when it should be subtracted. This may be because the
advertiser has canceled the user's transaction, either because he/she committed fraud or because
it has been a mistake entering the data needed to complete the campaign. If your account was transferred from the old system, to credit the user you must verify that the status value is 1, and to debit the user you must check that the value is equal to 2. If you wish to change it, contact your manager. |
{offer_id} | Id of the offer completed. |
{offer_name} | Name of the offer completed. |
{aff_sub} | The value that you used in the aff_sub parameter when you have loaded the offerwall. |
{aff_sub2} | The value that you used in the aff_sub2 parameter when you have loaded the offerwall. |
{aff_sub3} | The value that you used in the aff_sub3 parameter when you have loaded the offerwall. |
{aff_sub4} | The value that you used in the aff_sub4 parameter when you have loaded the offerwall. |
{goal_id} | For multi reward offers you can get the goal ID with this parameter. |
{transaction_id} | Unique identification code of the transaction made by your user on the offerwall. If an offer is rejected we will send a postback with the same transaction ID but with status "rejected". |
{ip} | The user's IP address who completed the action. |
{payout} | The offer payout in $ |
{signature} | MD5 hash that can be used to verify that the call has been made from our servers. |
As we use macros to build the postback URL, it's as simple as incorporating each macro in the place corresponding to the parameter value you want in the URL to which you want us to call. This way, you can use parameter names of your choice.
In the following example, we have decided to receive the value in our currency "points" in the parameter "pointsToReward" and the ID of the user on our website in the parameter "user".
https://exampleurl.com/postback/wannads?pointsToReward={reward}&user={user_id}
Our system IP is, 3.22.177.178 you should accept only postbacks coming from this IP address. If you want to secure the postback to ensure that the received call comes from our system, you will need to validate the signature we send. Below you can see how you should validate the signature.
Signature parameter should match MD5 of {user_id} {transaction_id} {reward} SECRET
You can find your secret in your app details.
<?php
$secret = ""; // check your app info, use the SECRET not the API SECRET
$user_id = isset($_GET['user_id']) ? $_GET['user_id'] : null;
$transaction_id = isset($_GET['transaction_id']) ? $_GET['transaction_id'] : null;
$reward = isset($_GET['reward']) ? $_GET['reward'] : null;
$signature = isset($_GET['signature']) ? $_GET['signature'] : null;
// validate signature
if(md5($user_id.$transaction_id.$reward.$secret) != $signature)
{
echo "ERROR: Signature doesn't match";
return;
}
?>
Our server will expect the following answers: OK or 1
Any other response will cause our server to mark the postback as failed.
Our servers wait for a response for a maximum time of 60 seconds before the 'timeout'. In this case, it will be retried sending the same transaction up to 5 occasions during the following hours. Please, check if the transaction ID sent to you was already entered in your database. This will prevent to give twice the same amount of virtual currency to the user because of the timeout.