End Statuses
In this section you become familiar with the following parts of the in-game payment integration procedure:
How to interpret the payment statuses returned by the payment callback function.
The table below gives an overview of the possible values associated to the callback status field.
The description related to each status gives more details on handling these statuses on your end (i.e. the game developer’s end).
| Status | Description |
|---|---|
| PAID |
The payment has been successfully completed.You can add the virtual currency to the user’s balance.Usually, a callback notification message with this status is sent once.If you don’t reply to this notification with the expected response, this call is repeated at regular intervals.Before processing this request check the payment request data you send, like:
Moreover, check that the virtual currency and real-world currency amount match. |
| FAILED | The payment has failed or has been canceled.Usually, a callback notification message with this status is sent once.If you don’t reply to this notification with the expected response, this call is repeated at regular intervals. |
| PARTIAL |
The payment was paused or it was only partially completed. A partially completed payment status can represent the following scenarios:
|
| IGNORE | You can safely ignore this notification. |
| CHARGEBACK | The payment was charged back.The Payment has been “completed”, for some reason (fraud of the card etc.), the money is returned to the user. Depending on your virtual economy or balance model, you can choose to revoke the amount from the virtual balance. |
| REFUND | The payment was refunded.Depending on your virtual economy or balance model, you can choose to revoke the amount from the virtual balance. |
| NOT_REFUNDABLE | A refund was requested, but the payment process does not support this action.You can safely ignore this notification. |
Examples
Note
When you copy-paste these examples, make sure you replace the dummy data with actual, valid data.
This PHP code example shows how the POST data response is built.
Notice how the hash is created ($myCalculatedHash variable), and then checked against the hash value included in the POST data to verify the transaction validity (if – else conditional flow statement}:
POST data$secret = 'd7e5aazq8klP'; // Your secret string. You use the same secret for all your games or applications. Contact Spil Games to request it.
$amount = $_POST['amount'];
$paidAmount = $_POST['paid_amount'];
$currency = $_POST['currency'];
$skuunit = $_POST['sku_unit'];
$skutype = $_POST['sku_type'];
$status = $_POST['status'];
$transactiontoken = $_POST['transaction_token'];
$userid = $_POST['user_id'];
$transactionid = $_POST['transaction_id'];
$myCalculatedHash = hash('sha256', "{$secret}{$amount}{$paidAmount}{$currency}{$skuunit}{$skutype}{$status}{$transactiontoken}{$userid}{$transactionid}");
if ($myCalculatedHash === $_POST['hash']) {
echo 'The hash checks out. The payment is valid.';
} else {
echo 'The hash is invalid. This payment does not originate from the Spil Games payment service. Do not process!';
} // End of the code example
Callback POST data example; the payment status is PAID:
(
[transaction_id] ⇒12345678 // Check this parameter to verify a transaction
[amount] ⇒ 123
[paid_amount] ⇒ 123
[game_id] ⇒ 175
[site_id] ⇒ 16
[channel_id] ⇒ 1
[package_id] ⇒ 12345
[sku_type] ⇒ MegaCoins
[sku_unit] ⇒ 100
[transaction_token] ⇒ unique-alphanumeric-string-1234
[custom_parameters] ⇒
[status] ⇒ PAID
[user_id] ⇒ phineasgauge1823
[internal_sku_name] ⇒ gamecoins
[created] ⇒ 2013-06-30 19:00:05
[lastmodified] ⇒ 2013-06-30 19:01:12
[paymentMethod] ⇒ sms
[provider] ⇒ payment-provider-name
[currency] ⇒ EUR
[hash] ⇒ f15da616592a0eb
[is_subscription] ⇒ 0
)