I have built a store on PrestaShop 1.6 that works in an unsupported by PayPal currency - BGN which at the moment has an exchange rate
1xEUR = 1.96 BGN
However, when a purchase is made the PayPal module sends the ex. 16,50 BGN as 8.00 EUR which should be 8.44 EUR.
Any idea what is going on and how can I fix this?
I found out that the problem was in the currency decimal sign. The platform was set to use no digits after the decimal sign so it was flooring the sum down.
If you have this problem go to Localization->Currencies->choose you currency-> turn on Decimals. That should be made to all currencies in order to work.
Related
In sandbox mode i am able to store credit card numbers, however when i retrieve it the card number is masked IE "xxxxxxxxxxxx1111".
The documentation states that it should be a numeric string.
Is this how it is supposed to work or does it just do this in the sandbox?
This is correct functionality. The full card number is hidden in the response, so the above information is accurate.
You'll find the information in the developer's page under Vaulted Credit Cards:
"The credit card number. Valid value is a string of numeric characters with no spaces or punctuation. Must conform to modulo and the length required by its credit card type. Redacted in responses."
https://developer.paypal.com/docs/api/vault/#credit-card_create_response
There's a pub in my town whereby, if you sign up to their newsletter using their website and provide a "unique" email address, you get a free drink. On a whim, I decided to sign up a second time using myemail+one#gmail.com. It let me. I'm now sitting on a nice comfy pile of free drink vouchers.
This got me thinking about a system we have here, where the email address is considered the unique identifier. Checking the code, sure enough, if we were offering vouchers in our business, someone else would be sitting pretty.
The basic, stab-in-the-dark, fix is to check for the "+" character and ignore everything after it (up to the #), and compare using that. But I am unsure if this was the intent for the + character. Would that work?
Secondly, are there any other caveats that would allow a user to sign up multiple times with a seemingly different email address, but which actually would always end up in the same mailbox?
This question is language-agnostic.
While using a plus sign as an e-mail address alias is a known feature of gmail, other mailers do either not allow it or use a minus sign instead. '+' is a legitimate character to be used as part of an email address according to the RFC.
The use of '.' is also a gray area. john.doe#gmail.com and johndoe#gmail.com send also both to the same email address and look different.
In order to validate the uniqueness of an email address you will have to prepare a rule base for your application, keep it up to date and still expect surprises...
We are unable to make the form for protocol 3 work correctly and getting a "5068 encryption method is not supported by this protocol version" message. The code we have for the encryption is shown below. Can anyone tell me where we are going wrong?
$stuff = #pkcs5_pad($stuff, 16);
$crypt = #base64_encode(#mcrypt_encrypt(MCRYPT_RIJNDAEL_128, $order['gateway']['transkey'], $stuff, MCRYPT_MODE_CBC, '1234567812345678'));
function pkcs5_pad ($text, $blocksize) {
$pad = $blocksize - (strlen($text) % $blocksize);
return $text . str_repeat(chr($pad), $pad);
}
Are you trying to use a simulator account for that request? If so, the version 3 protocol does not yet work with the simulator account, nor do Sage Pay have an estimate on when it will be available.
You will need to use a test account to test a full v3 integration, otherwise you can integrate to v2.23, commenting out the additional v3 fields, and test with the simulator account.
Then later on adding in the v3 additional fields and testing via the simulator when it's available or on a test account.
The encryption password will differ on your Test and Live account. If you require your encryption password please call our Support line on 0845 111 4455 who will be able to send it to a registered contact on the Sage Pay account.
If you are using Simulator - it is not available on v3.00. The above comment is correct, you may use v2.23 to test your integration. If ok, change to v3.00 ensuring your are checking all mandatory fields are being used and the return responses are ok.
V3.00 Form Protocol and Integration Guideline is available here. The Crypt field should contain all the other transaction information in plain text as Name=Value fields separated by ‘&’ characters. This string should then be encrypted using the AES/CBC/PCKS#5 algorithm and the pre-registered Encryption password, then subsequently Base64 encoded to allow safe transport in an HTML form. The crypt must be 16 characters.
If you need further support, you may email feedback#sagepay.com and reference this forum post URL.
Sage Pay Support
I am working with Paypal recurrent payments with NVP protocol and C# ASP MVC 4, but I think my question is valid for everybody working with paypal and recurring payments.
Are there any way to see the breakdown of a recurrent-payment ?
I mean, suppose today is 2013/01/01 and I set a recurrent payment with PROFILESTARTDATE set to 2013/02/01 and in this way :
Initial amount: 10€
Trial amount: 5€ - 3 monthly periods.
Subscription amount: 10€ - infinite monthly periods.
I would like to get a planning of my payments only to check all is rightly understood by paypal and I have not sending any confusing or erroneus data, more or less in this way:
2013/01/01 - 10 € (initial)
2013/02/01 - 5 € (trial)
2013/03/01 - 5 € (trial)
2013/04/01 - 5 € (trial)
2013/05/01 - 10 € (subscription)
2013/06/01 - 10 € (subscription)
2013/07/01 - 10 € (subscription)
2013/08/01 - 10 € (subscription)
2013/09/01 - 10 € (subscription)
.....
All of this with amount, taxes, item information and so on.
Any idea if this information can be obtained and how can I do it with the paypal-sandbox or with paypal-api-nvp ?
The paypal information for the test-user inside the sandbox is not giving me this information or I cannot find it.
So I have been using paypal, and sandbox mode everything works fine. Yet when I move over to live paypal with real money, IPN returns INVALID.
I am using a version of the script here ( https://cms.paypal.com/cms_content/US/en_US/files/developer/IPN_PHP_41.txt ) modified to my needs, only bits that are different are the db interactions etc
I have found this issue here ( http://www.hebtech.co.uk/blog/paypal-ipn-invalid-on-live-server-but-valid-on-test-server-fixed/ ) which seems to be the problem I am having, and basically says its to do with a carriage return in the optional second line of the address (which on test accounts in sandbox, isnt filled out). But the solution in the main post and another in the comments dont work, as below
$value = preg_replace('/(.*[^%^0^D])(%0A)(.*)/i','${1}%0D%0A${3}',$value);
OR
$value = preg_replace('/(.*?)(%0D%0A|%0A)(.*)/i','${1}%0D%0A${3}',$value);
Any ideas? Driving me mad. Its not stopping the payment, but it just means on the site, changing the status to paid has to be done manually
You can try this one:
$value = preg_replace('/%0D%0A|%0A/i','%0D%0A',$value);
I have also problem with character ; in custom field. Look in all fields you send to PayPall. Also check in all field any character which is not A-Z or 0-9.
Last thing you can try is set charset in your language encoding options: https://www.paypal.com/cgi-bin/webscr?cmd=_profile-language-encoding