I'm currently setting up the Paypal payment provider from Vendr.
I've gone through the whole setup process: set up the sandbox app and credentials, fired up ngrok, set up the setup the ngrok url in the PayPal webhook, set the webhook ID in Vendr.
I'm accessing the site through my ngrok URL, adding to cart, going to checkout, and when I go through the PayPal checkout and return to the site, I'm watching for the callback in the ngrok console and I see a "400 Bad Request" exception in ngrok from when PayPal tries to call the webhook.
I'm also working on setting up an authorize.net payment provider, and the webhook on that custom payment provider is giving me the same error. Not sure if they are related to the same issue though.
What am I missing here? Any help would be greatly appreciated.
If either of those two error, there should be a record of it in the trace log, but if there isn't anything showing up in there, you may need to pull the provider source code and debug into it.
Regarding your own provider, it's hard to say what the issue is there, but it could be similar issues. The providers will generally return 400 if they are unable to process the response, so you'll need to debug into them to find out where they are having problems.
The Paypal webhook calls started working a few hours later, weirdly. And the orders got marked as complete. Took about 4 hours for them to come back and process successfully. Wonder what would cause that to stop working for a few hours like that. I kept on seeing the calls in ngrok coming in but reporting a 400 error.
As far as the custom provider, I totally see where I messed up.
I was looking at some of the Payment Providers in Vendrhub that didn't have a GetOrderReference method and misunderstood the GetOrderReference method's purpose in the documentation. I was expecting the global webhook to call ProcessCallback instead of GetOrderReference.
Thanks for clarifying Matt! There's still no Authorize.net Payment Provider, right?
In all honesty, we've been hearing a lot of problems with PayPal not delivering webhook calls and we've been trying to work with them to get the issue resolved but they are being very illusive. We are currently just having to warn people that PayPal is being a bit flakey and that would couldn't entirely recommend them at the moment. Annoyingly they seem to work perfectly fine for some people, but not for others, and we have no way of knowing which is which. If you can use an alternative, I would probably recommend it.
RE Authorize, we don't have an official one yet, and nor have we seen anyone produce a community contributed one. Would love to feature yours if you wanted to contribute it back though.
Hey Matt, thanks for the update on the inconsistencies on PayPal Webhooks.
Sure, I'd definitely be willing to contribute the Provider when I have it all working properly.
I've noticed the clean structure of some of the other providers, mine is not that neatly structured, haha. It'd definitely need some cleaning up. Right now I'm just trying to get it all working and going through all the way.
I have everything (GenerateForm(), GetOrderReference(), and ProcessCallback() ) going through, I just have to write all the payment status check logic and such to mark the order.
I did run into a problem though that has me puzzled, Authorize.net employs a length limit on the InvoiceNumber of like 20 characters, so when I try to send GenerateOrderReference (which turns out to be like 60 characters), it bombs out and doesn't let me through. I've ended up just sending the OrderNumber and then fetching the reference when the Webhook comes back. I don't like it, but at least its working while I work on the stuff ahead of it.
I can't quite remember how Authorize.net works, whether you have one global webhook handler defined in their portal, or whether you send a callback URL as part of the payment setup.
The order reference is only really need, as is the GetOrderReference method if you are using a globally registered webhook. This is because global webhooks don't have an order context and so we need a method to work out which order the webhook relates to. If you send the webhook URL as part of the payment setup, these aren't needed as we give the GenerateForm method a vendrCallbackUrl that is already structured with order information in, so this would already know which order it relates to.
If you do require a global webhook, and if they support other custom meta data, you could store the reference somewhere else. The reference is essentially the order number + order ID, so as long as you store those two parts somewhere, you can always reconstruct an order reference.
Hope this gives you some ideas on how to progress, and look forward to seeing what you come up with.
That was my first thought. Sending the reference in custom data. But they don't support any custom data to be returned by the webhook.
Currently we don't support returning custom fields in webhooks. We can see the value, you can submit this to ideas page. Our team will evaluate it.
Also, they have one global webhook handler that you set up in their system which sends the notifications back as events are happening in their system (auth, capture, refund, void, etc). Or at least that's the way I understand it.
The webhook returns the invoiceNumber (OrderNumber) I sent through in generate form though, so I grab that, GetOrder(StoreId, OrderNumber), grab the ID, and reconstruct the reference, then send it through.
That's the only way I can think of to get around their character limit on the invoice numbers since no custom data is supported.
400 Bad Request Error on webhook callback from Paypal
Hello Vendr,
I'm currently setting up the Paypal payment provider from Vendr.
I've gone through the whole setup process: set up the sandbox app and credentials, fired up ngrok, set up the setup the ngrok url in the PayPal webhook, set the webhook ID in Vendr.
I'm accessing the site through my ngrok URL, adding to cart, going to checkout, and when I go through the PayPal checkout and return to the site, I'm watching for the callback in the ngrok console and I see a "400 Bad Request" exception in ngrok from when PayPal tries to call the webhook.
I'm also working on setting up an authorize.net payment provider, and the webhook on that custom payment provider is giving me the same error. Not sure if they are related to the same issue though.
What am I missing here? Any help would be greatly appreciated.
Hey Alex,
With the PayPal provider, generally speaking this would either suggest the
GetOrderReferencemethod is failing https://github.com/vendrhub/vendr-payment-provider-paypal/blob/dev/src/Vendr.PaymentProviders.PayPal/PayPalCheckoutOneTimePaymentProvider.cs#L36, or the callback method is not being able to process the callback body https://github.com/vendrhub/vendr-payment-provider-paypal/blob/dev/src/Vendr.PaymentProviders.PayPal/PayPalCheckoutOneTimePaymentProvider.cs#L127If either of those two error, there should be a record of it in the trace log, but if there isn't anything showing up in there, you may need to pull the provider source code and debug into it.
Regarding your own provider, it's hard to say what the issue is there, but it could be similar issues. The providers will generally return 400 if they are unable to process the response, so you'll need to debug into them to find out where they are having problems.
Matt
The Paypal webhook calls started working a few hours later, weirdly. And the orders got marked as complete. Took about 4 hours for them to come back and process successfully. Wonder what would cause that to stop working for a few hours like that. I kept on seeing the calls in ngrok coming in but reporting a 400 error.
As far as the custom provider, I totally see where I messed up.
I was looking at some of the Payment Providers in Vendrhub that didn't have a GetOrderReference method and misunderstood the GetOrderReference method's purpose in the documentation. I was expecting the global webhook to call ProcessCallback instead of GetOrderReference.
Thanks for clarifying Matt! There's still no Authorize.net Payment Provider, right?
Hey Alex,
In all honesty, we've been hearing a lot of problems with PayPal not delivering webhook calls and we've been trying to work with them to get the issue resolved but they are being very illusive. We are currently just having to warn people that PayPal is being a bit flakey and that would couldn't entirely recommend them at the moment. Annoyingly they seem to work perfectly fine for some people, but not for others, and we have no way of knowing which is which. If you can use an alternative, I would probably recommend it.
RE Authorize, we don't have an official one yet, and nor have we seen anyone produce a community contributed one. Would love to feature yours if you wanted to contribute it back though.
Matt
Hey Matt, thanks for the update on the inconsistencies on PayPal Webhooks.
Sure, I'd definitely be willing to contribute the Provider when I have it all working properly.
I've noticed the clean structure of some of the other providers, mine is not that neatly structured, haha. It'd definitely need some cleaning up. Right now I'm just trying to get it all working and going through all the way.
I have everything (GenerateForm(), GetOrderReference(), and ProcessCallback() ) going through, I just have to write all the payment status check logic and such to mark the order.
I did run into a problem though that has me puzzled, Authorize.net employs a length limit on the InvoiceNumber of like 20 characters, so when I try to send GenerateOrderReference (which turns out to be like 60 characters), it bombs out and doesn't let me through. I've ended up just sending the OrderNumber and then fetching the reference when the Webhook comes back. I don't like it, but at least its working while I work on the stuff ahead of it.
Any ideas on how to get around that length limit?
I can't quite remember how Authorize.net works, whether you have one global webhook handler defined in their portal, or whether you send a callback URL as part of the payment setup.
The order reference is only really need, as is the GetOrderReference method if you are using a globally registered webhook. This is because global webhooks don't have an order context and so we need a method to work out which order the webhook relates to. If you send the webhook URL as part of the payment setup, these aren't needed as we give the GenerateForm method a vendrCallbackUrl that is already structured with order information in, so this would already know which order it relates to.
If you do require a global webhook, and if they support other custom meta data, you could store the reference somewhere else. The reference is essentially the order number + order ID, so as long as you store those two parts somewhere, you can always reconstruct an order reference.
Hope this gives you some ideas on how to progress, and look forward to seeing what you come up with.
Matt
That was my first thought. Sending the reference in custom data. But they don't support any custom data to be returned by the webhook.
Also, they have one global webhook handler that you set up in their system which sends the notifications back as events are happening in their system (auth, capture, refund, void, etc). Or at least that's the way I understand it.
The webhook returns the invoiceNumber (OrderNumber) I sent through in generate form though, so I grab that, GetOrder(StoreId, OrderNumber), grab the ID, and reconstruct the reference, then send it through.
That's the only way I can think of to get around their character limit on the invoice numbers since no custom data is supported.
is working on a reply...