Bitpay Transactions Do Not Update In Blesta

[cloudrck]

After upgrading from 3.3.2 to 3.4.0, I've had a new customer account pay by Bitpay, it never showed up in the Blesta control panel, not even in pending. The payment was confirmed by Bitpay, but it never made it back to Blesta. So the invoice is never marked as paid, as there is no transaction that shows up. Checking the logs through the panel shows no error messages, just one Bitpay line with one Input and one Output, both successful. I know before there is usually several for one payment. I should note that the invoice was overpaid, but not sure if that would/should make a difference.

 

Also, seems Bitpay has created a new API since I first started using it. I'm still using the Legacy API Key, rather than the new API token system. Not sure if Blesta has changed this or not.

 

 

Running Blesta v3.4.0, Debian/MariaDB/Nginx

[Michael]

It depends on the time frame you have for it to show up on Blesta. 

[cloudrck]

It depends on the time frame you have for it to show up on Blesta. 

No, that's not the issue. The payment has been confirmed via Bitpay and the Bitcoin network, it's been three days. As I've said before, nothing has changed except for the upgrade. Blesta has no clue the payment was even pending. There's a disconnect between Bitpay & Blesta.

[Tyson]

What is contained in the gateway logs?

 

I think you should have log information similar to the following:

1. Client goes to make a payment. Before redirecting them to BitPay, Blesta notifies BitPay of the payment and receives a reply (logged).
2. Client makes a payment at BitPay.
3. BitPay notifies Blesta within an hour regarding the payment (logged).
4. Blesta asks BitPay to confirm the payment has been made, and gets a reply (logged).
5. Blesta determines whether to accept the payment based on the response from BitPay, and a transaction is created.

As long as BitPay's API is backward compatible, the gateway should still work this way.

[cloudrck]

Seems as if only step 1 & 2 are being executed.

 

INPUT

 

";s:17:"notificationEmail";s:23:"<<USER_EMAIL>>";s:11:"redirectURL";s:120:"https://my.cloudrck.com/index.php/order/checkout/complete/OpenVZ/<SOME_HASH>?price=20&posData=329=20.0000&currency=USD";s:8:"currency";s:3:"USD";s:16:"transactionSpeed";s:4:"high";s:7:"posData";s:11:"329=20.0000";s:8:"itemDesc";s:12:"Invoice #328";s:8:"physical";b:0;s:9:"buyerName";s:11:"< NAME >";s:13:"buyerAddress1";s:12:"< ADDY >";s:13:"buyerAddress2";b:0;s:9:"buyerCity";s:6:"< CITY>";s:10:"buyerState";s:5:"< STATE>";s:8:"buyerZip";s:5:"73301";s:12:"buyerCountry";s:13:"<COUNTRY>";s:10:"buyerEmail";b:0;s:10:"buyerPhone";b:0;}

 

 

INPUT

 

 

https://bitpay.com/invoice?id=< DATA >
a:15:{s:2:"id";s:22:"< DATA >";s:3:"url";s:52:"https://bitpay.com/invoice?id=< DATA >";s:7:"posData";s:78:"{"posData":"329=20.0000","hash":"< DATA >"}";s:6:"status";s:3:"new";s:8:"btcPrice";s:8:"0.085815";s:5:"price";i:20;s:8:"currency";s:3:"USD";s:11:"invoiceTime";i:1422043882341;s:14:"expirationTime";i:1422044782341;s:11:"currentTime";i:1422043882597;s:7:"btcPaid";s:8:"0.000000";s:6:"btcDue";s:8:"< DATA >";s:4:"rate";d:233.06;s:15:"exceptionStatus";b:0;s:11:"buyerFields";a:8:{s:9:"buyerName";s:11:"< DATA >";s:13:"buyerAddress1";s:12:"< DATA >";s:13:"buyerAddress2";b:0;s:9:"buyerCity";s:6:"< DATA >";s:10:"buyerState";s:5:"< DATA >";s:8:"buyerZip";s:5:"73301";s:10:"buyerEmail";b:0;s:10:"buyerPhone";b:0;}}

 

 

Both are successful.

[Tyson]

The second log is OUTPUT, correct?

 

If those are the only logs, then it looks like Blesta handles sending the client to BitPay, but BitPay is either not replying to Blesta, or that reply is lost somewhere along the way.

 

I haven't looked at their latest API, but if they modified the return data sent to Blesta after a payment is made, it could be failing if Blesta can no longer interpret it in the same way. I would expect there to be an error if this were the case, which you may be able to find in your php error logs within an hour of the time the payment was made. Otherwise, you may want to take a look at BitPay and make sure there isn't some new configuration setting that may be refusing to send callbacks.

[cloudrck]

Ok, could it be that Maxmind rejected the order? This client was obvious scammer, using an anon proxy which I have set to "review", but he made it to Bitpay, paid, and it confirmed with Bitpay. But Blesta/Maxmind appears to have not liked the order, there's a red X in the billing/overview on that order.

 

If this is the case, why would he be allowed to pay, and if he paid why would it not show up as pending in Blesta. I'll look into it tomorrow if I have the time.

[Paul]

Ok, could it be that Maxmind rejected the order? This client was obvious scammer, using an anon proxy which I have set to "review", but he made it to Bitpay, paid, and it confirmed with Bitpay. But Blesta/Maxmind appears to have not liked the order, there's a red X in the billing/overview on that order.

 

If this is the case, why would he be allowed to pay, and if he paid why would it not show up as pending in Blesta. I'll look into it tomorrow if I have the time.

 

Maxmind and the order system will not prevent payments from being made. The red X simply indicates that payment has not been received, as evidence by the invoice not being marked paid. If the Bitpay payment was settled, then there may be an issue with that information being passed back to Blesta. In my experience, with the default settings, it would take about an hour for Bitpay payments to appear in Blesta but it sounds like much more time than that has passed.

[Blesta Addons]

Maxmind and the order system will not prevent payments from being made.

so what is the benifict here from using maxmind ?

normally if maxmind refuse the order , or class it as a high risk level , blesta should get this in consideration and reject/accept the order based of maxmind result .

and that laso should be the same for any other fraud system protection .

[Paul]

so what is the benifict here from using maxmind ?

normally if maxmind refuse the order , or class it as a high risk level , blesta should get this in consideration and reject/accept the order based of maxmind result .

and that laso should be the same for any other fraud system protection .

 

The order system can hold an order for "review", such that even if it is paid it will not be provisioned. Services are by default set to "in-review", and the order system marks those services related to an order as "pending", once the order is approved. If maxmind or the settings prevent an order from being approved, the services ordered will never be activated.

 

Payment is completely separate, and the order system cannot prevent a payment from being made. Some orders, even if they are assumed by Maxmind to be fraudulent may not be and the best course of action is for Staff to review the order.

[Blesta Addons]

The order system can hold an order for "review", such that even if it is paid it will not be provisioned. Services are by default set to "in-review", and the order system marks those services related to an order as "pending", once the order is approved. If maxmind or the settings prevent an order from being approved, the services ordered will never be activated.

 

Payment is completely separate, and the order system cannot prevent a payment from being made. Some orders, even if they are assumed by Maxmind to be fraudulent may not be and the best course of action is for Staff to review the order.

that make sense now for me .