Once your users start generating sales, you'll want your system to sync the associated data so that you can show these sales to your users, send push notifications, etc. There are two ways to get this transaction data: pull them from our API or receive callbacks from our system. In most cases, you'll want to receive callbacks to keep your system in sync as closely as possible, but you'll also want to hit the API to pull batches of transactions in case a callback wasn't successful. At this time, we do not re-attempt failed callbacks.
Getting Commission Data via the Wildfire API
To see the API docs for how to fetch transaction data see the API reference.
Getting Commission Data via Callbacks
To set up your callback URL, in your partner admin tool, select the application you want to configure and then select the gear icon. Here you can enter a callback URL (please ensure it's an HTTPS endpoint) and a callback key. The callback key can be any value. The purpose of the callback key is to ensure that the callback is valid (and that a rogue entity is not invoking your callback URL with false data).
Once you have configured your callback settings, if you have any sales data, you can select the "resend callback" icon next to the sale and it will send the callback payload to your callback URL. You can use this feature to test that your callback settings are configured correctly.
Callback Header Data
A callback request will have a POST body similar to this:
Action: "create", "update"
Payload Key Values
ID: Unique ID for this commission, when update are sent this ID will be the same.
ApplicationID: The ID of the application that triggered the call.
DeviceID: The ID for the users device that made the purchase.
Sale Amount: Reported sale amount from merchant. Note: Some merchants don't report sale amount, this can be 0. Additionally, this amount uses the original currency in which the purchase was made. This value is not converted to the application default currency.
Amount: The commission amount, this can be a negative number in the case of a canceled or returned order to offset the original commission (this will have a new ID). This amount is always converted to your application's default currency (e.g. if your default currency is CAD, this value will be sent via API and callback in CAD).
- “Pending” is the default state of a new transaction that is expected to earn a commission amount (not disqualified).
- “Ready” indicates that the merchant has paid us for the commission and the payment is just awaiting the next payment cycle (at the beginning of each month).
- “Paid” indicates that the record has been paid to the partner (and the user, if Wildfire pays users on behalf of the partner), and the transaction should be included in the relevant payment report.
- “Disqualified” indicates that the transaction was not eligible for earning. Some merchants don't report these records. Others (like Ticketmaster) report these records. An example of a “Disqualified” sale is a pre-sale ticket.
TrackingCode: This is the value referred to in this article.
EventDate: Timestamp for when the order was placed.
CreatedDate: Timestamp for when the commission was entered into our database.
ModifiedDate: Timestamp for the last time this commission was modified in our database.
MerchantOrderID: Order ID provided by the merchant for this transaction. Note:This value may be blank, not every merchant reports an order ID.
MerchantSKU: SKU number for item purchased. Note: This value may be blank, not every merchant reports SKU values.
And the headers will look like this:
Note the "X-WF-Signature" value is the HMAC encoded value of the POST body using a sha256 encoding type and using the Callback Key value that you set. A PHP example for how to generate this signature (to compare it to the one in the headers to verify that the request is authentic) looks like this:
$post_body = file_get_contents('php://input');
$signature = hash_hmac("sha256", $post_body, $callback_key);
At the time of the writing of this article, Wildfire does not support retrying failed callbacks. We do intend to add this feature in the future, but in the meantime we recommend using the API calls on a regular basis (i.e. daily) to compensate for the possibility of incomplete callbacks.