Skip to main content

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

StatusDescriptionFinal?
createdTransaction registered, the customer has not made a payment yetNo
processingPayment is being processed by the operatorNo
paidPayment completed successfullyYes
canceledTransaction canceled (timeout, rejection, customer cancellation)Yes

State diagram

State transition descriptions

createdprocessing

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.

processingpaid

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.

processingcanceled

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

createdcanceled

The customer took no action and the transaction expired (timeout).

Behavior per payment method

Different payment methods have different lifecycle patterns:

MethodGoes through processing?Typical time for payment
BLIKYes~2 minutes (code validity)
Bank transfers (PBL)YesUp to 15 minutes
Payment cardsYes (authorization + optionally 3DS)Up to 5 minutes
Google Pay / Apple PayYesSeconds
MB WAYYes (confirmation in app)Up to 5 minutes
BizumYes (confirmation in app)Up to 5 minutes
DCBYesUp to 2 minutes
SMS PremiumNot applicable (different model)-

How to check the transaction status?

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.

info

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.

tip

Do not query the API too frequently. The recommended approach is:

  1. Primary mechanism - IPN (automatic, immediate)
  2. Fallback - a cron job checking the statuses of transactions pending for more than 15 minutes

Mapping statuses to IPN

Transaction statusIPN sent?IPN type
createdNo-
processingNo-
paidYestransfer
paid (card capture)Yescapture
canceledNo-

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;
}
warning

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.