-
Notifications
You must be signed in to change notification settings - Fork 162
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Integration Question (Payment's timeouting) #2498
Comments
Hello @Lord225, The default duration for which an order code remains active is 30 minutes. However, if you are using the create payment order API, you have the flexibility to change the default duration by editing the "paymentTimeout" parameter. For documentation on how to do this, please refer to this guide: https://developer.vivawallet.com/apis-for-payments/payment-api/#tag/Marketplace-Payments/paths/~1checkout~1v2~1orders~1/post. If you make a webhook call after the specified duration of 30 minutes, you can consider the response final. For a more comprehensive understanding of the StatusId parameter in the webhook, I recommend referring to the analytical documentation available at https://developer.vivawallet.com/integration-reference/response-codes/#statusid-parameter. Additionally, please take into account the information provided in the red box outlined in this guide: https://developer.vivawallet.com/webhooks-for-payments/#webhook-events. Kind regards, |
I understand that and I know I can change timeout - the thing is that sometimes webhook with confirmation can come after very long time even if timeout is set very low (like 5 minutes). I noticed this behavior with blik payments. Sometimes it is instant but it can take several minutes and I'm not sure how I can check if payment has expired and cannot be payed or it has been payed but is not yet verifed. |
Hello @Lord225, Thank you for your prompt response. Kindly note that this can happen in Asynchronous payment methods. Asynchronous payment methods are those in which payments are not confirmed immediately (synchronously). In essence, these rely on a delayed payment notification (via webhooks) before the payment can be confirmed as complete. In any case, when you receive a webhook notification, before updating a transaction’s status on your system, you SHOULD always retrieve its details from Viva. Please use the transactionId in the payload and make a call to the Retrieve Transaction API. Validate the orderCode, statusId and amount you received in the Retrieve Transaction API response and update your system accordingly Kind regards, |
Hello @Lord225, This ticket will close for now. Please don't hesitate to raise a new ticket if you need further assistance. Kind regards, |
Hello, I integrated this API a year ago, and it works. However, I have one issue I would like to resolve, but I don't know if the API has the necessary tooling. Last time I checked, there was no good way of checking if a payment is currently being processed or if it has expired with no possibility for the payment to be completed. Because the API can be slow (I found out the hard way that webhooks can take up to a few minutes to come), the best thing I've come across is to just wait a bit (20 minutes) and assume that if webhook have not come yet it will never. I really want to fix that. Is there a way now to check if a payment has expired and cannot be processed? The best thing I've come across (that wasn't available previously) is this link: https://developer.vivawallet.com/apis-for-payments/payment-api/#tag/Payments/paths/
1api1orders~1{orderCode}/get and the StateId field, but it is not really well documented. If the payment has a StateId of "Expired," can I assume it will not finish? And if it remains pending after the expiration time, does that mean it has been paid but your system has yet to confirm the payment with the bank and probably will finish sucessfuly in near future?Also I have diffrent question - is there an robust way to check if webhook with transation was created by terminal or by my API call?
The text was updated successfully, but these errors were encountered: