PayPal Community

I would certainly activate a dispute, although even for charge backs PayPal does not have a very good record, certainly not like a decent Merchant Bank that would give you a week or two to reply sending them any documents / references you might wish to include.   Digital Downloads and Charge backs: Sadly that's the one area of ecommerce that  BADLY idles along way behind other advances made by the providers. But don't languish, always initiate a dispute and go over your user agreements and terms of use and clearly make them available for download links etc. That at least can be offered to the provider as some ammunition against the fraudsters who simply cause a return of funds.   You might find this PP video from innovate09 Panel Discussion: Digital Goods interesting (although perhaps depressing)     Regards, ----------------------------------------------------------------- 'imself. [PHParagon.com] [Save MySQL] ...bug free, my programs do occasionally include undisclosed FREE random features.   ... View more

Have another look at the PP refund process. Refunds can be made through PP WPS accounts and fees are returned also.   See "If I send a refund and it is accepted, are the fees from the original transaction credited to my account?"   ------------------------------   Note if you are using so called plain text button forms, ie NOT EWP encrypted, NOT account button wizard encrypted, NOT "saved hosted" button wizard html forms, it is possible for script kiddies (inc general low iq idiots) to copy your form even on their PC desktop and after making changes submit their remote copy of the form design.   But realize, squilions of dollars are earnt by happy PP clients like your selves using the WPS pay button forms every year (er, that's overall not squils each).   The more experienced webmaster realises that with PP the refund process is easy, and if the payment was for a product one MUST use proper result reconciliation no matter how confident one is. At the end of the day that is where the buck stops(!!), result checking.   Programmaticly that can be as easy as implementing IPN notifications, with the server side processor script performing fundamental checks of receiver address etc PLUS the total cost received compared to the product ordered. If there is a problem detected don't ship the product and have an email sent to you warning you of the possible nong attack. If it is an obvious attack activate a "refund".   Really, if you are impatient, think everything should just happen easily and no extensive checking should be required, you shouldn't even own a computer. Don't blame stuff on others or other systems where money transactions are concerned. YOU (or your code) MUST CHECK PROPERLY BEFORE SHIPMENT.   So all the kiddie attack suggestions above can be considered as common, not terrific, but still common.   PS Edit: For general good-guys use of your pay button forms, apply some basic Javascript checking of the forms before they are submitted. As one person above suggested some just inattentively do stuff like enter 1 instead of 10.00 etc; it happens all the time. So a bit of Javascript can in *most cases sort that out for you especially where you are expecting the customer to enter summink in a text box (*Javascript can be easily circumvented if somebod really wants to).   See skier's web site for form samples many accompanied by easily adjusted Javascript ideas.   --------------------------- PS EDIT: I forgot this most important bit....   Chargeback Fee To cover the cost of processing chargebacks, PayPal assesses a fee to sellers for credit and debit card payment chargebacks. (A chargeback occurs when a buyer rejects or reverses a charge on his or her credit card through the credit card issuer). So it is not hard to understand why many sellers insist on only buyers using a PayPal accounts!!   So it is always worth initiating a refund as quick as possible when the need is obvious.   This Fee is based on the currency received as follows: Argentine Peso:     30.00ARS Australian Dollar:    $15.00 AUD Brazilian Real:         20.00 BRL Canadian Dollar:     $15.00 CAD Czech Koruna:         250.00 CZK Danish Koruna:         60.00 DKK Euro:             €11.25 EUR Hong Kong Dollar:     $75.00 HKD Hungarian Forint:     2000 HUF Israeli Shekel:         40.00 ILS Japanese Yen:         ¥1,300 JPY Mexican Peso:         $110.00 MXN New Zealand Dollar:     $15.00 NZD Norwegian Krone:     65.00 NOK Philippine Peso:     500.00 PHP Polish Zlotych:         30.00 PLN Singapore Dollar:     $15.00 SGD Swedish Krona:         80.00 SEK Swiss Franc:         10.00 CHF Taiwan New Dollar:    330.00 TWD Thai Baht:         360.00 THB U.K. Pounds Sterling:     £7.00 GBP U.S. Dollar:         $10.00 USD This Fee does not apply if the transaction is covered by PayPal’s Seller Protection Policy (eBay items).   Regards, ----------------------------------------------------------------- 'imself. [PHParagon.com] [Save MySQL] ...bug free, my programs do occasionally include undisclosed FREE random features.   Translate   ... View more

Your original post sounded like you are using the account button wizard saved "hosted" html form code.   If that's the case...   ...then the idea of "hosted" button forms is to NOT allow any changes to the form design that can affect the final price (ie only what you set up in the wizard).   Only way around that is to return to the wizard in your seller account and either...   1) RE-create the original saved button with changes and copying the new generated html code. Note most non item form fields not affecting the prices can be manually added to the extras box or later directly to the copied form html.   2) When recreating the saved button (or producing a new one) DO NOT SAVE the button design (stage 2) and use the resulting html code that way (deselecting the "encryption" option if preferred).   Regards, ----------------------------------------------------------------- 'imself. [PHParagon.com] [Save MySQL] ...bug free, my programs do occasionally include undisclosed FREE random features.   ... View more

"...easy..."   Probably the easiest method is to use "Mass Payments" ("mass" = one or many at a time). You can do it manually via Seller Account interface or programmaticly.   Even if advancing to the newer API methods you will have to perform some server side programming.   Whatever, the recipients must have PP accounts too.   But if to be performed by you, PP WPS "Subscriptions" are not an option.   Regards, ----------------------------------------------------------------- 'imself. [PHParagon.com] [Save MySQL] ...bug free, my programs do occasionally include undisclosed FREE random features. ... View more

WPS Subscriptions require the subscriber to have an existing PP account (or create simply by adding a password).   So of course if you were to obtain that account info you can do whatever you want to, set up your own button forms or whatever. But of course you could also drain their accounts!!   However, it is NOT logical that, although in your mind your intention is honorable, anyone could cause anyone else to become subscribed to whatever one wants to just get their money... you just need to have their PP account info to do so (or ccard info if by any other provider).   So what's the difference, with their supplied details they sign up or you sign up for them?   As for just charging an account when ever you want to and outside the terms of the subscription would also mean the system is wide open to abuse.   ...and then if YOU the seller activates the payment, when ever, that IS NOT a subscription service but simply a series of individual payments you organize with anothers account info.   Alternatively you might consider using "Mass Payments" you can readily organize programmaticly or manually via your seller account interface.   Now using a PP WPPro account and the new APIs one can get a bit closer whereby one can acquire a customers permission to make "recurring" deductions and then process them on their behalf programmaticly when needed, even making cost changes readily. In fact there are a couple of options one could pursue through the APIs.   Regards, ----------------------------------------------------------------- 'imself. [PHParagon.com] [Save MySQL] ...bug free, my programs do occasionally include undisclosed FREE random features.   Translate   ... View more

I don't believe you can do what you are hoping for.   All transactions and contacts between PP and your customers and PP and you have to refer to one account.   What you are hoping for is akin to becoming an anonymous seller (even if in your mind that is not your intention) and for legalities plus I guess as well as for ethics that is a no-no.   So as described by skier, you can do all the other stuff but ultimately the transactions are between or manged by the one same seller.   The alternative of course wholly implying they are completely separate accounts is to use just that, two PP accounts.   I have seen over recent years sellers using an implied commonality for business management with simple public caveats to that effect in emails and thank-you pages etc. But to actually HIDE origin I am quite sure will not work.     Regards, ----------------------------------------------------------------- 'imself. [PHParagon.com] [Save MySQL] ...bug free, my programs do occasionally include undisclosed FREE random features.   ... View more

To use button form fields you can study "HTML Variables for Displaying PayPal Checkout Pages".   But the preferred cleaner method is to use the Seller account "Profile" -> "Custom Payment Pages" where you can setup a number of named "styles" and set any one of them as the default.   Then if you want to use another style on a particular form just use a name="style" value="stylename" to override the default.   Profile -> "Business Information" is another area you may want to adjust business defaults also.   Regards, ----------------------------------------------------------------- 'imself. [PHParagon.com] [Save MySQL] ...bug free, my programs do occasionally include undisclosed FREE random features.     ... View more

u/l case should not be a problem but try it anyway.   Also go to seller account Profile -> Language Encoding -> [BUTTON: More Options] -> More Encoding Options where you can set the default as UTF-8 and the second option as "Yes" (or select UTF-8 if not chosen in the first option) .   ...plus... charset...  Optional Sets the character encoding for the billing information/log-in page, for the information you send to PayPal in your HTML button code, and for the information that PayPal returns to you as a result of checkout processes initiated by the payment button. The default is based on the character encoding settings in your account profile. For allowable values, see Setting the Character Set – charset.   IPN Of course one must carefully check the logic paths in your IPN code to see if it's the logic that determines the INVALID and not the actual match to data received (ie too often the INVALID is just output as an if / else statement result not matching the first 'if' but not an explicit check of the alternate PP return).   Also, is the rebuilt return string of the received POST data stream correctly URI encoding the NVP values correctly? Also worth a double check.   Last but not least, proper debug by simply saving to a text file the captured RAW "POST" data followed by the built Q string before it is sent back to PP. Do some tests as previously mentioned and view the text file contents. Also if using a pre processing language like PHP compare the RAW data stream BEFORE the RAW POST data.   Regards, ----------------------------------------------------------------- 'imself. [PHParagon.com] [Save MySQL] ...bug free, my programs do occasionally include undisclosed FREE random features.   ... View more

Appears most complaining here seem to overlook or are even unaware of the HUGE differences between use of a free-to-use PayPal WPS payment method and general widely used merchant services accounts.   Anything PP WPS is where your customer spends most of their time performing a transaction with PP ON the PP payments pages website. The main privilege that comes with having the customer perform the transaction between themselves and PayPal on the PP site is YOU (the seller) only have to pay per transaction...   1) Pay NO annual or monthly fees (the actual PP account is "FREE-to-use").   2) Pay per transaction fees ONLY.   But if the commercially more widely used merchant method is involved where YOU have to obtain a "Bank Merchant Account" PLUS an agreement contract with one of that banks accepted "Gateway Providers" you have to...   1) Pay annual and monthly fees for the Merchant Account.   2) Pay annual (and possibly monthly) fees for the Gateway Provider.   3) Pay card provider fees for each transaction.   However, one of the most attractive aspects pf PP WPS accounts that helps make PP so popular in the "toy" ecommerce processing market is the fact that sellers from quite a few countries around the world can transact in the money type of their country of residence therefore not losing any value where otherwise exchange rates would alter their income considerably when obtaining the accounts funds. Combine that and the WPS free-to-use accounts and PP are hard to beat.   You the sellers / merchants (even small turnover sellers) have to create the competitiveness of possible alternatives.   It is only when / if the likes of Google and Amazon ever do the same where international accounts are concerned that they will become ultimate formidable competitors... although I don't understand why US sellers don't bother to ALSO incorporate those others as alternative payment providers just to assist in the long term growth and competitiveness  of them... ie Google / Amazon - that part is up to you.     Regards, ----------------------------------------------------------------- 'imself. [PHParagon.com] [Save MySQL] ...bug free, my programs do occasionally include undisclosed FREE random features.     ... View more

Have you included in your WPS pay button form...   <input type="hidden" name="charset" value="UTF-8">   Check how your IPN processor reacts to that.   (ps note for testing careful copying of the character from your PP email can assist and re-pasting the char somewhere in a Sandbox pay button form ie a hidden "custom" value" too as well as a ccard name can help sort it - here's an old favorite from the pre PP "x" forums I use all the time... C�u Azul)     Regards, ----------------------------------------------------------------- 'imself. [PHParagon.com] [Save MySQL] ...bug free, my programs do occasionally include undisclosed FREE random features.   ... View more