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
Related
I'm trying to read out a tachograph company smart card. I can read all data just fine except the identification part. Which is the part I actually need. When I select that DF the security environment is reset and I have to re-authenticate. This process is described in sub appendix-11 of ECE/TRANS/SC.1/2006/2/Add.1. Although this document is a bit hard to understand for me.
In this picture you see the data structure of a tachograph company card. The "AUT" behind the ID part tells you that you need to authenticate.
After asking another question on SO and doing a lot of research on how public/private keys are used I think I have some basic understanding on how I should do the authentication. In the documentation, there is also a pretty detailed flow chart on how to get the authentication done. It's to big unfortunately to place here. But I have a question about this part:
Now, I'm counting from the top, downwards. So the first top left square is step one, the last bottom left is step 7. The middle section arrows are APDU commands that need to be send to the card, and the right section is the smart card. PK means public key. CA means certificate authority.
If you do not know the public keys, you see you need to get both the card and the CA certificate. I've done that and I can read them from the card. The part I don't understand are step 6 and 7. You see I need to verify the Card CA.C (which is some part of the certificate) with the European Public key. Where do I get the European public key and what algorithm is used to decrypt it?
EDIT:
Is this the Verification process? And if so, it says to open the sign with the CA public key, How do I get this?
EDIT 2:
I've found the European public key from this link. The CAR part of the CA certificate on the card matches the first 8 bytes from the public key. Meaning it is the correct public key. Now If I understand correctly, I need to Open the sign following step three from CSM_019 from the picture above. To open the sign, I need the correct algorithm using the public key I quess? Does anyone know what algorithm is used?
Step 6: Nothing to decrypt here: You verify the signature, also part of the certificate (Card.CA.C), and if it is correct the contained key (public key of card CA) may be extracted and used for the next step.
Step 7: You verify the signature of card certificate (made with the card.ca key just retrieved) and if it is correct you now have the public key of the card (with the certainty, that it is correct, otherwise signature would have mismatched).
The scheme uses this two-step approach, so that only the Eur.PK public key is needed instead of the keys of all card CAs.
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.
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 was able to add a recipient to an envelope with a recipientId that was the HASH of the recipient's email address (50a5ae9b6d8889c1fda3f140621b448b). However, I was not able to add tabs to that recipient. I was able to edit the recipient name and email address, so the system seems to be able to recognize the recipientId. It appears to be a problem with the recipientId in the URL since adding tabs is the only REST API call that uses the recipientId in the URL.
After more testing, I found that there is a limit of 32 characters to the length of the recipientId but you can still edit the recipient and assign a recipientId that is not valid (alphanumeric and/or greater than 32 characters).
I'm seeing different results, and seeing the system act as expected here. First off, if I try to add a 32 digit number for the recipientId such as
12345678901234567890123456789012
I'm able to add the recipient just fine, then subsequently modify their tabs. Next, if I try an alpha numeric string, such as (notice the z at the end)
1234567890123456789012345678901z
The system generates an error stating INVALID_RECIPIENT_ID - A recipient ID is missing or invalid. I also get this error if I try a completely numeric number that is greater than 32 digits in length.
Please re-test and confirm your results, as this appears to be functioning as designed.