I'm wrapping up my express checkout integration. So far, so good. Only possible problem is I need to supply MerchantID in paypal.checkout.setup(..), something like this was not needed in classic EC. Because I'm implementing on an ecommerce system with many stores, but same code, this presents a bit of a struggle.
What I noticed is that if I simply put an empty string for ID, the checkout process completes successfully on sandbox.
My fairly short question is how mandatory is that ID, since it's only needed for In-Context checkout and practically any string works? Can I skip it?
Thanks!
The field is not exactly mandatory. You are not required to put in your email address or your Merchant ID. It's used for tracking with PayPal using In-Context. However, in order to generate the button you will need to keep a space in the field.
paypal.checkout.setup(' ', {
container: 'myContainer',
environment: 'production'
});
Related
I am hoping someone here can help me as I have been on to PayPal technical support who haven't been very helpful.
I am integrating PayPal checkout, following the instructions here: https://developer.paypal.com/docs/checkout/standard/integrate/
I wish to collect the paypal transaction ID in my database, send order confirmation emails etc... so as such I need to implement the optional step 5 described in this integration guide, which essentially means creating two routes on my server, one to call "create order" and one to call "capture order" - as per the sample code here: https://developer.paypal.com/demo/checkout/#/pattern/server
I have got this working successfully however I wish to know 2 things:
How can I see the 3D Secure flow - PayPal tell me know to worry about it as they handle it within the popup window but I would like to see the flow. I have tried test cards that should invoke the 3DS flow but they dont show any 3DS flow, just complete the payment.
The response to the capture order end point can return multiple statuses (COMPLETED, APPROVED, VOIDED, PAYER_ACTION_REQUIRED etc). Is it only the "COMPLETED" status that means a fully completed payment (and therefore I should complete the order)? What happens if it returns "PAYER_ACTION_REQUIRED" - which means 3DS check needed - will PayPal handle this and then re-execute my route?
Any help or advice would be greatly appreciated.
For the normal, 'Standard' integration, you don't have to test 3DS. The PayPal page/iframe already takes care of everything about it.
[Only for the 'Advanced' integration -- where you are implementing individual hosted card fields with your own styling -- do you need to implement and test 3DS yourself]
PAYER_ACTION_REQUIRED only happens with Advanced. All you need to do on the server end after the capture is check for COMPLETED and the existence of the Capture Id you're going to store for accounting purposes.
I'm using ASP.Net Membership Provider for logging into the premium content of this web site. The content isn't downloads, it's web pages of information and discounts, etc. That part is done. We want them to also have a PayPal Subscription annual payment to see the premium content. I would like ASP Membership and PayPal Subscription to work together as much as possible, but for the minimum I am thinking they will have to create a MemberId before they pay. Then I will send that MemberId to PayPal to associate the two.
I think I can do that like this:
Set "Auto Return" on in the interface so that it will redirect to return URL when payment is made.
Set "return URL" query string to MemberId. This requires not using the precompiled "Saved" buttons. I'll have to set it in Code Behind with Name Value Pairs, "NVP" to PayPal. I was hoping to just paste the stupid button.
But then, there were those "Advanced Variables" in the Button maker. Problem was they are compiled into the Saved button, so I can't change them for each person. But maybe that one parameter could be separate from the compiled parameters? Is this better than hacking the return URL? Are "Advanced Variables" good for anything?
All the details about the transaction will be POSTed to the return URL if I put in the right code, which might be rm=2. (Right?) Then I can record it.
This process is said to be unreliable, though, and PayPal recommends using a secondary system that they have, "IPN". PayPal sends the transaction details to me. I send them back http 200 code. Then I send it back to them in the same order I got it. Then they send me http 200. Then we all know it's good. This sounds like a few hours research to me, but if you've already done it once, it sounds like copy and paste. I hate reinventing the wheel. Is there a .Net sample of this IPN handshake/dance?
Also, if I do the IPN thing, maybe I don't need Auto Return. Maybe I add MemberId to "notify" URL instead of "return" URL. Then PayPal can handle the confirmation page, email, etc. Is that better?
Assuming we get the Subscription paid for and recorded with the MemberId, at least once per user session, after they log in, I have to check if they have paid their PayPal subscription and if it's up to date. "GetRecurringPaymentsProfileDetails" does this, but it is an API operation. That makes sense, but I was hoping to avoid learning their REST API. (Is there a "NVP" version?)
REST API OAUTH tokens expire every few minutes, but the only way it tells to get one is by using "Bash" to "cURL" some Linux commands. Again, this seems like the kind of thing that would only ever have to be written once. Does this already exist as a sample code somewhere?
(I don't want to use the API to do the Subscribe, because I don't want the Credit Card numbers to ever go to our site. Too much liability. That's why I wanted PayPal.)
Will this even work? I know PayPal has 18 ways to do everything and they all exclude each other, and I'm just getting the feeling that I'm creating a patchwork of unrelated ideas to fool myself into believing there's a light at the end of the tunnel. I've already been researching and experimenting for 10 hours or so. I really thought, going in, I'd just be pasting a stupid button.
If you want to just "copy the stupid button" then you'll have to stick to Payments Standard, and then you'll be limited with what you can do. For example, you won't be able to use GetRecurringPaymentsProfileDetails for a standard subscription.
Instead, you'll need to use Express Checkout and / or Payments Pro. There is indeed an NVP API available for these, and there is also a SOAP/XML version. Details on those can be found here: https://developer.paypal.com/docs/classic/api/
Specifically, for Express Checkout, you'll want SetExpressCheckout, GetExpressCheckoutDetails, DoExpressCheckoutPayment, and CreateRecurringPaymentsProfile. Some of those calls are optional depending on how exactly you're configuring things with the checkout flow.
For Payments Pro you'll use either DoDirectPayment / CreateRecurringPaymentsProfile or PayFlow depending on what version they put you on.
In any case, IPN is definitely the way to go for post-transaction processing.
.NET IPN Sample - https://github.com/paypal/ipn-code-samples/blob/master/paypal_ipn.asp
I'm adding very simple membership renewal functionality to a web site using PayPal Payments Standard buttons. We only have 300 or so members, so a simple e-comm solution like this should work fine.
I'd like to capture some sort of confirmation that I can then capture on my end so that I can insert it into the database. I've seen the IPN listener method, but it seems more complex than I really need - all I really need is to pass the confirmation code via a URL variable in the return URL, i.e. http://www.example.com/landing?transactionid=abc123. Is this possible? Also, is there a way to pass my own dynamic variable (for instance, a membership ID) into the form and have that be a part of the return string?
Thanks
An alternative is to use express checkout which is a two step process requiring pre-authorization and then charging a customer. If you are accepting echecks you will eventually need to use IPN to update the original transaction. You can pass a dynamic variable using the custom field in Paypal.
Either way one of the two methods is required to process a transaction securely - what is stopping someone from typing the URL you are suggesting?
I have a website where I am using Cart66 that sends orders to PayPal Express.
Assuming the customer does not have nor wish to create a PayPal account:
When going through desktop - the customer gets a chance to add notes to merchant/seller. However, when using mobile, there is no such field.
Cart66 support says it is a PayPal issue... But I have been over all setings I can find... But maybe i am missing something obvious?
Seems like in-context does not support it yet
https://developer.paypal.com/docs/classic/express-checkout/in-context/popup/
https://developer.paypal.com/docs/classic/express-checkout/in-context/integration/
(That said, inspecting the Cart66 - they are not calling the new "In-Context" URL that is specified in requirements, but I still that it the reason)
I'm using the callback API to prevent someone selecting a non-UK shipping address. I've supplied a callback url, I've set CALLBACKVERSION to 61.0.
When I go into the sandbox and choose an address I know the callback page is being called as I've added code to email me the values submitted to it and the value returned to PayPal. For anything with a SHIPTOCOUNTRY that isn't GB the response is
METHOD=CallbackResponse&NO_SHIPPING_OPTION_DETAILS=1
I've also tried setting a fuller response in case it doesn't like some required field to be missing
METHOD=CallbackResponse&CURRENCYCODE=GBP&L_SHIPPINGOPTIONNAME0=Standard&L_SHIPPINGALABEL0=Standard&L_SHIPPINGAMOUNT0=2.95&L_SHIPPINGOPTIONISDEFAULT0=true&L_SHIPPINGOPTIONNAME1=Express&L_SHIPPINGALABEL1=Express&L_SHIPPINGAMOUNT1=5.95&L_SHIPPINGOPTIONISDEFAULT1=false&NO_SHIPPING_OPTION_DETAILS=1
But it's still allowing non-UK addresses and just using the shipping options set during the initial set up request.
Any suggestions on where I'm going wrong?
After opening a ticket as suggested by PayPal_Patrick the problem was that I was adding the callbackversion in the wrong place. The full response to reject a shipping address on callback is:
METHOD=CallbackResponse&NO_SHIPPING_OPTION_DETAILS=1&CALLBACKVERSION=61
There are different transaction ID's for Buyer and Seller accounts.
I think this might be an issue caused by the country associated with the buyer account being used. I'm going to reach out to the product team for Express Checkout and see if it is intended functionality or not - I don't believe it would be.
If you want to stay updated on the issue I would recommend creating a ticket to PayPal.com/mts, give me the ticket number, I'll grab it and keep you involved.