signature request API wrong url - paypal

When I do a Paypal API signature request under business profile, the generated api is using my old website ---whateverAPI.my-old-website.com
I've updated all of my business information and see no instances of the old url in my paypal account or the developer or sandbox accounts.
I do not have the old login information for developer area where I created the original API information as it was changed to my new login/business.
I need to change the URL associated with my account so the api generated has the apicode.new-website.com
I know this is a low level expertise for most of you compared to what you are coding but I am completely stuck and have tried everything I can think of.
Thanks for taking the time to read!

When the API is first requested on an account, it is generated based on the email address associated with the account at the time. Even if you remove the email address and request new API credentials, it will still use that original email address. There is no need for concern, you only set this in your API call or in your shopping cart to use. Buyers are not going to see it or anything, and it's not something you would regularly share or have to use all that often. Once you set it in your code, you don't really mess with it again unless you need to set up the API credentials again.

Related

New API keys in Mandrill by default have full access to your account - can you customize?

In Mandrill, if you create a new API key and do not limit its API calls, whoever you give that key to can use it to log into the web interface with full access - billing information, account information, the works.
After playing around, it looks like you can disable the web interface login functionality by ticking "Only Allow This Key To Use Certain API Calls" and then selecting at least one API call. Doesn't matter which one.
So I can give full access to the account, or completely disable their ability to log in. Is there any way to customize this further? I would like to be able to limit users to the outbound/inbound UI, or at least prevent them from having the ability to charge many thousands of dollars to the attached credit card. For clarification, my use case is to distribute API keys to contractors or vendors so that all email gets sent through a single account.
I have found very little official Mandrill documentation on this. The only thing that seemed relevant is that if you have a Mailchimp account, you can instead send users there and use the "View Mandrill Reports" functionality. I don't have Mailchimp (nor do I need it), so this seems like an unnecessary hacky workaround.
Different levels of access, other than limiting API calls for API keys isn't currently possible as described in the Mandrill KB here. If someone has access to the web interface, they have access to the account as a whole. This may, of course, change in the future, and would be documented on the blog and in the KB.
I believe you could also restrict access to the web interface by setting up two-factor authentication?

Paypal "SetExpressCheckout" API method has stopped working with sandbox seller account

My application uses the SetExpressCheckout paypal classic API method. It is working fine when I use real accounts in a live environment.
It used to work fine using test accounts, but some weeks ago it has stopped working right. At some point, my application calls the "SetExpressCheckout" API method using curl in PHP. When I use the test seller account that I've always used for my tests, I always get the following error:
SetExpressCheckout API call failed.
Detailed Error Message: Security header is not valid
Short Error Message: Security error
Error Code: 10002
Error Severity Code: Error
I know that paypal has recently restructured its "developer network", and the issue seems to be caused by this but I have no proof of that. The API I used is now called the "classic" API.
I've read the documentation, and it says that I now have to create a new "real" paypal account, and then use it to log to https://developer.paypal.com. I did that.
Once logged to the developer website, there is a feature allowing us to import all the test buyer and seller accounts used in an old sandbox account. I did that, and my old test accounts appeared in a list.
One of them is the test seller account I used to test. When I check the details of this account, the username, password and signature used to authenticate to the paypal API are there. If I use them, it still returns the previous error.
There is also a feature allowing me to create test accounts. I've created a new seller, and still, I get the same error message.
When I search on google about this issue, most answers says that the username, password or signature are wrong or have hidden white spaces in them. That's not my case.
I don't know how to solve that problem. I am wondering if the API endpoint has changed. I currently use "https://api-3t.paypal.com/nvp" for tests. I am using the NVP API, version 64.
To make it short:
1) My test account used to work
2) The code has not been modified
3) Real accounts used to work and still work.
4) But test buyer account has stopped working
5) The issue chronologically coincide with paypal "developer network" restructuring.
6) I don't know what has changed exactly and might cause this.
7) Does anyone know what has changed and might has caused this (a new parameter in the query string? Endpoint URL changed?)?
8) According to my previous description, do I seem to have misunderstood something, and what?
I currently use "https://api-3t.paypal.com/nvp" for tests.
That's your problem. You're using test credentials, but the live API endpoint.
Change your endpoint to https://api-3t.sandbox.paypal.com/nvp and all should be fine.
Security header is not valid means that your credentials are incorrect. I've never once seen that error where this wasn't the case.
You need to make sure that if you're using sandbox credentials for testing that you're hitting the correct endpoint and using the correct credentials.
Lots of times people accidentally have sandbox credentials set but then send them to the live endpoint or visa versa. If you're hitting the correct endpoint and your credentials are indeed correct you won't get this error.

CreateAndSend Invoices User Access

So I was able to test CreateAndSend Successfully in sandbox, and have now moved my credentials to the live versions.
I created a new business account for using the live version, and have gotten my api credentials for it.
Replaced API ID,PASS,SIGNATURE with those credentials.
Connecting to svcs.paypal.com/Invoice/CreateAndSendnvoice.
and an error I'm getting back is user is not allowed to perform this action.
I set the merchant and payeremail to my email (I tried the paypal email and then the api1 email)
I was wondering if my paypal account needs to be verified to do this API call.
Thank you.
Make sure that you have a live app id and that it is approved for this feature.
Following up on this. Having my business account verified fixed the "user is not allowed to perform this action" problem I was having.

how to validate username in paypal

Is there any way to use some paypal api for validation of username in paypal?
Google didn't give much :( and using such method isn't comfortable, cause there are too many requested parameters(for example, i know user's email, but i don't even want to know his adress,etc.).
PayPal doesn't provide such an API and for a very good reason.
Remember - it's being constantly under a lot of pressure from scammers around the world that are trying to steal other people's money. Just imagine the phishing power one might get by being able to pre-validate the email addresses to see if they really are current PayPal users and then crafting a targetted email attack on them...
Such an API (to see if a random email address is registered with a PayPal account holder) does not and never will exist for security reasons. With possibly one exception - "trusted partners", where PayPal partners up with a big and established entity and allows special API permissions (based on secure credentials), but this is not something a mere mortal could ever hope for.
Furthermore, if a workaround is discovered that allows to do just that - rest assured PayPal will patch that hole ASAP to avoid security breach.

Social Network (Facebook, Twitter, etc) User Account Integration (duplicate scenario)

So there are definitely many tutorials out there regarding how to integrate various individual social network authentication/registration into existing user accounts. But the scenario I can't seem to find out much information about is if a user signs into your account with different social network credentials. For example:
Scenario #1
User registers on site using site's authentication.
User then signs in/registers on site using Facebook Connect.
User then signs in/registers on site using Twitter.
How do I integrate all of these into one account?
Obviously once a user is registered, they can add other social network associations in the account settings pages. But I am more concerned if they register via the other social network not remembering they are already setup.
My general thoughts are trying to figure out a way to use the "username" or email to try and guess and present the user a way to combine accounts right there.
Anyone have any thoughts?
following up -
if your users can't remember that they've signed up previously, well, best of luck to them in general ;)
much as you described, i'm planning on giving users the option to link additional accounts once they have signed in by one means or another.
but as far as cross-checking, there's only so much you can do. many social network APIs do indeed provide email addresses (once you've busted in through OAuth) but these may be accessible only if a user has elected to make his/her address public, which is not guaranteed.
also not guaranteed is that the user used the SAME email address for each social network account, so even if you manage to retrieve an address it may or not be of any use to you.
finally, if you find matching email addresses via such means, it might be advisable to prompt the user to link accounts rather than assume he/she wants this done automatically. some people like to maintain multiple personalities. i.e. "it looks like you are also signed up with twitter - do you want to link your accounts? it will make your life seem worth living."
you might consider offering incentives to link user accounts or to provide an email address (up to you of course to figure out what these might be, based on the functionality of your website).
solution i am working on, database-side, is to maintain multiple accounts and then if link information is discovered by various means, said link is indicated in a lookup table.
an alternative is once you find a link, attempt to combine all relevant entries for the multiple accounts into one account entity - all i can say about this latter approach is that i would do so with caution as there could be a formidable level of complexity depending on the user's activity level and the complexity of your database schema.
in my (mental/actual) namespace a user who registers the old-fashioned way has a 'standard' account and one who uses a social network has an 'alias' account. then the goal becomes to define where the alias is supposed to point, i.e. create the lookup such that a subsequent login via either means retrieves the relevant information for both accounts (with a preference for displaying personal data for the 'standard' account).
btw i figured out how to make twitter OAuth behave since my last post - you can look at my other answers for details if you're interested.
JB
hi matt,
i'm working on the same problem right
now.
assuming the user starts with regular
site account (which is not
necessarily safe to assume if he sees
all the pretty "connect with XXX
network" buttons!!!), you can use
either OAuth or the javascript APIs
(facebookConnect or #anywhere -
haven't fully figured out the latter
yet and i'm not sure I recommend it as
I don't think it provides as rich an
API as do the backend libraries) to
login to the other sites.
the APIs should return certain
information after a successful
login/redirect from the social network
- such as the user ID and an ACCESS TOKEN which you can then store in your
database in some capacity associating
your 'actual' application user with
the ID of the social network.
when the user returns to the site, you
can then
1 verify cookies set by the social
network services (various schemes
typically verifying a signature, based
on sha1 or md5 hash of your
application data - by which i mean the
data you get when you register your
app with twitter/facebook, typically a
consumer key, application ID, etc. -
with the received cookies) so you know
the user has logged in with the social
network
2 find your database entry association
as described above
3 login your user manually based on
the assumption that facebook/twitter
connection is secure.
caveat: this is only as secure as your
implementation (or as secure as
facebook/twitter's implementations, if
you prefer...)
although twitter's OAuth does not
currently seem to work quite right,
their general description of the
process is pretty informative:
http://dev.twitter.com/pages/auth
good luck.
J
I have been contemplating adding FB auth to our app, but we know that our returning users might click it and complete checkout for a new item, and then be surprised to not see any of their existing orders. To solve this, when a user clicks the 'Login with Facebook' item, we are using that click to fire a dropdown menu with two options:
[ Login with Facebook ]
[ Create new account ]
[ I have an account ]
If the user clicks 'I have an account' we send them to FB auth and return email from FB to our app. We compare that email to our existing users. If we match, we add the FB creds to the user. If no match, we throw an alert:
The email you have with FB does not match any of our accounts. To log in to your existing account, login with your email below, or update the email in your Facebook account
This allows the user to create a whole new account, if they want to keep them separate, without needing a new email service. While this is an edge case, it is a feature.