Transaction Lifecycle
Every transaction in dpay.pl goes through specific states - from creation to final settlement or cancellation. Understanding the transaction lifecycle allows you to handle payments correctly in your application.
Transaction statuses
| Status | Description | Final? |
|---|---|---|
created | Transaction registered, the customer has not made a payment yet | No |
processing | Payment is being processed by the operator | No |
paid | Payment completed successfully | Yes |
canceled | Transaction canceled (timeout, rejection, customer cancellation) | Yes |
State diagram
State transition descriptions
created → processing
The customer selected a payment method and started the authorization process. For some methods (e.g., BLIK, cards), the transition to processing occurs immediately after the payment data is submitted.
processing → paid
The payment operator (bank, BLIK, card processor) confirmed the authorization. Funds have been debited from the customer's account. dpay.pl sends an IPN with the confirmation.
processing → canceled
The payment failed. Most common causes:
- Customer canceled the payment
- Invalid BLIK code or rejection in the banking app
- Insufficient funds
- Timeout (customer did not complete the payment within the required time)
- Rejected by the anti-fraud system
created → canceled
The customer took no action and the transaction expired (timeout).
Behavior per payment method
Different payment methods have different lifecycle patterns:
| Method | Goes through processing? | Typical time for payment |
|---|---|---|
| BLIK | Yes | ~2 minutes (code validity) |
| Bank transfers (PBL) | Yes | Up to 15 minutes |
| Payment cards | Yes (authorization + optionally 3DS) | Up to 5 minutes |
| Google Pay / Apple Pay | Yes | Seconds |
| MB WAY | Yes (confirmation in app) | Up to 5 minutes |
| Bizum | Yes (confirmation in app) | Up to 5 minutes |
| DCB | Yes | Up to 2 minutes |
| SMS Premium | Not applicable (different model) | - |
How to check the transaction status?
IPN (recommended)
The best way to track the transaction status is through IPN handling. dpay.pl automatically sends an HTTP POST notification to your endpoint when the transaction transitions to the paid state.
IPN is sent only for successful transactions (status paid). Canceled transactions do not generate IPN notifications.
Polling (API querying)
If the IPN did not arrive or you need additional verification, you can check the status yourself:
POST https://panel.dpay.pl/api/v1/pbl/details
Content-Type: application/json
{
"service": "abc123",
"transaction_id": "A75AEBB4-4B89-4834-AD43-EF442C133769",
"checksum": "sha256(service|transaction_id|secret_hash)"
}
For endpoint details and code examples, see the Querying the transaction status manually section.
Do not query the API too frequently. The recommended approach is:
- Primary mechanism - IPN (automatic, immediate)
- Fallback - a cron job checking the statuses of transactions pending for more than 15 minutes
Mapping statuses to IPN
| Transaction status | IPN sent? | IPN type |
|---|---|---|
created | No | - |
processing | No | - |
paid | Yes | transfer |
paid (card capture) | Yes | capture |
canceled | No | - |
Handling states in your application
Example logic for handling statuses on your server:
// Mapping dpay.pl statuses to order statuses
switch ($transactionStatus) {
case 'created':
// Order awaiting payment
// Display "Awaiting payment" message to the customer
break;
case 'processing':
// Payment in progress - do not change the order status
// Customer sees the waiting page
break;
case 'paid':
// Payment confirmed via IPN
// Update the order, send a confirmation email
markOrderAsPaid($orderId);
break;
case 'canceled':
// Transaction canceled
// Restore product availability, inform the customer
markOrderAsCanceled($orderId);
break;
}
Do not update the order status to paid based on the customer redirect to url_success. The only reliable sources of information about a successful payment are IPN and a query to the dpay API.