PayPal subscription api has stopped working - paypal

My site has been creating subscription payments for years using the classic form-post method to PayPal's cgi-bin/webscr URL.
Suddenly this has stopped working. The webscr page is called but just displays blank. Is something broken, or have PayPal changed something? There's no info to suggest the API is deprecated or anything.
I tried the "create a button" method, and using the generated html (which also calls webscr) it works. I can't use this live because some of the parameters are calculated by JS on my page, a standard button is too simplistic.
Does anyone know what's going on?
Thanks

To round this off, I have discovered the cause, and it's ultimately mea culpa. I went through my code with a fine tooth comb, and for some reason the following line appeared twice in my button form html:
<input type="hidden" name="cmd" value="_xclick-subscriptions">
Probably an ancient copy-paste error. This never caused any problem until recently, but obviously there's been some tightening of validation by PayPal.
Removing the duplicate line has restored the original functionality.
Sometimes the simplest things can be the hardest to find!

Related

How Remove Odd Hidden Web Field in My Form

I'm redoing some stuff on a website. I create my own forms and there's been a hidden field injected into my system somehow, after my Submit button. I have (updated) found that it is injected by Square payment processor (95% confidence). But it does not show up on my published site, only my workstation.
<input name="nds-pmd" type="hidden" value="{"jvqtrgQngn":{"oq":"1440:1595:1440:1706:1440:2560","wfi":"flap-138151","oc":"q400qo6n8n86q525","fe":"1440k2560 24","qvqgm":"300","jxe":135975,"syi":"snyfr","si":"si,btt,zc4,jroz","sn":"sn,zcrt,btt,jni","us":"q7008390np2s6777","cy":"ZnpVagry","sg":"{\"zgc\":0,\"gf\":snyfr,\"gr\":snyfr}","sp":"{\"gp\":gehr,\"ap\":gehr}","sf":"gehr","jt":"78r9qs3735260548","sz":"54p61p7n7s97rn3","vce":"apvc,0,5r54nr06,2,1;fg,0,,0,,0,,0,,6,,0;zz,11583,1p9,121,f_nq_cebsvyr_pbhagel;gf,0,11583;zzf,3r9,0,n,231 163,798 27,34n,34n,-28rp,2787,-568;zzf,3r7,3r7,n,45 0,122q 0,221,220,-16n0,9s60,snq;zzf,3r8,3r8,n,0 9r,7058 201,1666,164o,-3r062,22786,-10nn;zzf,3r8,3r8,n,45 27,2063 2n0n,q13,q00,-opp0,r62n,355q;zz,rq,429,278,;zzf,2sp,3r8,n,2sp 1nr,p3qo 3170,2484,2490,-55s3n,5q156,-2rnr;zzf,3rp,3rp,n,ABC;zzf,3r5,3r6,n,ABC;zzf,3r9,3r9,n,ABC;zzf,3r9,3r9,n,ABC;zzf,3r8,3r8,n,ABC;zzf,2717,2717,32,ABC;gf,0,163nr;zzf,270r,270r,32,ABC;zzf,2713,2713,32,ABC;gf,0,1o1ps;zzf,2711,2711,32,ABC;zzf,2711,2711,32,ABC;gf,0,1sss1;zzf,270s,270s,32,ABC;zzf,rn67,rn67,1r,ABC;gf,0,31167;zzf,rn67,rn66,1r,ABC;gf,0,3sopr;zzf,rn60,rn61,1r,ABC;gf,0,4r62r;zzf,rn64,rn64,1r,ABC;gf,0,5q092;zzf,rn62,rn62,1r,ABC;gf,0,6ons4;zz,o93o,540,2n0,;gf,0,7742s;zz,oq54,500,1o,pbyyncfvoyrAnione;gf,0,83183;xx,s78,0,f_nq_cebsvyr_anzr;ss,3,f_nq_cebsvyr_anzr;zz,960,24q,1n6,;so,2s2,f_nq_cebsvyr_anzr;zz,2914,57p,2o5,;gf,0,87664;xx,48q,0,f_nq_cebsvyr_anzr;ss,0,f_nq_cebsvyr_anzr;so,147,f_nq_cebsvyr_anzr;xx,4,0,f_nq_cebsvyr_pbzcnal;ss,0,f_nq_cebsvyr_pbzcnal;zp,15,150,os,f_nq_cebsvyr_pbzcnal;zp,4s,150,os,f_nq_cebsvyr_pbzcnal;so,qpo,f_nq_cebsvyr_pbzcnal;zz,12,234,1r1,;xx,1q76,0,f_nq_cebsvyr_pbzcnal;ss,3,f_nq_cebsvyr_pbzcnal;zz,np,26r,17o,f_nq_cebsvyr_hey;so,1os,f_nq_cebsvyr_pbzcnal;xx,3,0,f_nq_cebsvyr_hey;ss,1,f_nq_cebsvyr_hey;zp,8n,270,17o,f_nq_cebsvyr_hey;so,qqs,f_nq_cebsvyr_hey;gf,0,8o8pr;zz,396o,522,140,;xx,315,0,f_nq_cebsvyr_hey;gf,0,8s54r;ss,0,f_nq_cebsvyr_hey;so,n55,f_nq_cebsvyr_hey;","ns":""},"jg":"1.j-952168.1.2.fVkluNjuPtiX7Vz4XSTgDD,,.mAaD01S5Ua73V84EfsG1-uOIddNorAK-95Azs1LvMa0uvVIaED2hQNisAwd1fTk6qFNCd4_spoDT2y2hGdBtS-J4nYKw_tRoHws_-BjCJvskfveCoDIdUiA8gKgtHY_8ssdVnS4P2YZ_tTqtFWLKudkmBMwTEhnDl3-2Eingfx7fmrVZwPPbvb6yYPMsOLJD2kTSqr78jmmpmh2iOoNem9GwMmJ1YGtybtCKAcG2KNxCDgLzd0b0OHQsA1Fki15J"}">
I'm using Chrome. This now (updated) looks like some Square injection. I'm finding it on Safari and Firefox as well, same values inside the field. Again, it is not showing up on my production served site.
Update.
No JavaScript injection. The payment processor was responsible, and I had never seen this before.

Created a custom styled PayPal checkout button on Shopify, but I was previously told this wasn't possible

As the subject states, I created a PayPal Checkout button by simply adding the HTML code for the button and modified the text and remove the PayPal logo image.
Normally the code below would be used to generate the button, which of course is limiting:
{{ content_for_additional_checkout_buttons }}
However, I have instead added this HTML in its stead:
<div class="paypal-checkout-button">
<button name="goto_pp" type="submit" id="paypal-express-button" class="additional-checkout-button additional-checkout-button--paypal-express" value="paypal_express">
CHECKOUT WITH PAYPAL
</button>
</div>
The button's functionality is perfectly fine; I even processed a test payment through it. A developer friend of mine told me it wasn't possible without some hacky solution; however, the simple HTML snippet above seems to be a perfect solution to customizing the PayPal button on the cart / product page.
Am I missing anything? Or is this perfectly fine to do?
Appreciate any you can provide on the matter.
It's not the button on the cart that Shopify people have issues/problems with.
It's the button on the checkout and that can't be modified (without a lot of hassle) unless the store owner has a Plus account. That is almost certainly what your developer friend is talking about.
Not to mention, of course, that changing the appearance of the button or forcing it not to appear before the Shopify checkout process is a violation of the PayPal express user agreement.

PayPal HTML buttons broken for large shopping carts on new PayPal checkout

Been battling for weeks with a PayPal Payment Standard FORM problem.
We have been running the same code for many years but noticed our larger invoices (with over 20 items) on them were hitting a white screen of death recently when submitting to PayPal. Testing in the Sandbox worked just fine as before.
After searching everywhere I couldn't find anyone else with this exact problem but noticed if we took the invoice down from say 60 items to 7 items then the invoices seemed to go thru ok. Seems to be a POST buffer problem at PayPals end?
The problem we found was that there is a 502 redirection problem from https://www.paypal.com/cgi-bin/webscr to the new checkout which has /hermes or similar within the URL.
The answer I found was to force the use of the old checkout system at all times using
<input type="hidden" name="force_sa" value="true">
Here is a very simple example with 66 items
http://www.whatsanip.com/paypal_bad.html
this will hit the WSOD as it is trying to use the new checkout and seems to hit a 502 error when redirecting
BUT
add
<input type="hidden" name="force_sa" value="true">
to the input and we will be sent to the old checkout system which works just great. See same URL as above but swap in _good.html to see the good version that sticks to the old checkout page (i wasnt allowed to add more than 2 links)
Another quirk is that my text editor (Ultraedit) has an in built browser for testing, if submitting from this then it will go thru ok to the old checkout (i think ultraedit is using an old IE implentation).
Any PayPal employees here? Should I submit a bug? If anyone can get _bad.html to work I would be very interested as many hours have been spent investigating this.

Paypal checkout opens on a separate tab - how to change this?

I have found that the Paypal generated buttons is a very good solution for my wife's website. However, whenever someone presses on the "add to cart" button, he/she is taken to a separate Internet Explorer tab. That's fine. However, if they chose to "continue shopping", IE tries to close the Paypal tab and asks the user's permission to do so. This is not really ideal from the user experience point of view.
Can I force the Paypal Checkout to open in the same IE tab as the main website?
Thank you.
The PayPal Standard shopping cart will always function that way. I highly recommend you go with your own shopping cart instead. That way there are no new windows/tabs at all, and the redirection doesn't happen until the person is ready to pay.
There are lots of options for doing this. You could build a cart into your site as a custom solution, or what would be even better would be to go with something like WordPress and WooCommerce.
To avoid redirecting to a different tab, you can use minicart PayPal plugin.
You just need to include the following lines of code inside your
<script>
paypal.minicart.render();
</script>
MiniJS Demo
I had this issue as well, in your check out button you should have target="_self" like this:
<form id="paypal-checkout-button" target="_self" action="https://www.sandbox.paypal.com/cgi-bin/webscr" method="post">
Don't mess around guys!
Just remove target="paypal" attribute from the paypal form.
<form target="paypal" action="https://www.paypal.com/cgi-bin/webscr" >
change to
<form action="https://www.paypal.com/cgi-bin/webscr" >
This will now open paypal in the same tab/page of the browser.

IPN / PDT PAYPAL Headache

UPDATED!
I managed to get a dynamic receipt using PDT, screenshot here: http://pastebin.com/4RcTdHKd which is generated from my pdt.php here: http://pastebin.com/4RcTdHKd
Now is the question how do I manipulate the variable tx to get whats needed, for example the transaction ID to dynamically show / or not show downloadable audio/video content?
Is it a good idea to on this .php have all (there aret THAT many files) downloadable files available, but as input type=hidden and just have some condition or IF statements that check if the product id = downloadable hidden id?
I got some tips using the following code to access but havent solved it yet:
$tx_token = $_GET['tx'];
First, IPN and PDT are two completely different systems. PDT is used more for a return page, to create a dynamic receipt. IPN is used more for updating your shopping cart, database, or system. You do know what your IPN and PDT script to be the same page, as this can cause some problems. You will want to have an IPN script separate from your PDT script.
As for getting the transaction id, you can use something similar to this:
$tx_token = $_GET['tx'];
And then you can just echo out the response on to the page. You can find sample of a PDT PHP script at https://www.x.com/developers/PayPal/documentation-tools/code-sample/216627 that may better help you, or give you a working example to build off of. There are a few different ways you can incorporate this into your wordpress site, all which depend on your current set up and which option works best for you. Some merchants use plugins and use the code with their plugins, and others use an iframe and have the PDT script within an iframe.
Hope this helps. :)