Does PayPal's GetVerifiedStatus `belong' to the api caller's country? - paypal

I'm wanting to verify accounts for a service I have. It seems all the accounts from the USA work, but as soon as someone from overseas attempts to verify their account the api doesn't work.
I am receiving the error 580022: Cannot determine PayPal account status. Is each region hidden from each other?

There is no such restriction on verifying the international PayPal accounts too . Make sure you have passed the correct email address and the first n Last name .
I just tried to verify a "Trinidad and Tobago" account and it worked fine for me .
Apart from that make sure that if the person has middle name as well then don't include it in the API call . Just pass the first and the last name .

Related

signature request API wrong url

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.

Paypal sandbox account could not be created

When I try to create a business sandbox account it first has a status of processing but then always results in an error status code. It says the sandbox account could not be created, please delete it and create another one.
I saw that the paypal forms have some validation issues so I have already tried the following:
Password more than 8 characters containing uppercase,lowercase,numbers and symbol characters.
Positive balance < $1000
Valid fictional email address that is not the same as my address.
Tried different countries including the US.
Filled in the optional fields of first name and last name
But still the same error.
I solved this by using a different browser. So I guess this was cache related in some way. I entered the following data:
Country: United States
Didn't fill in optional fields
Bank verified
Visa
$100 in account
I used Microsoft Edge instead of Chrome.

Dwolla reflector off-site test account and Payment Activity

Using the off-site test account (Dwolla Reflector), I am able to get a successful transaction indicated by status=Completed. I also get all of the expected results including an empty transactionid, valid signature, checkout id etc.. when in test mode. However, no payment activity in my account at all.
The documentation for the reflector doesn't specify usage of test-mode or not. My assumption was a test account would be in test-mode but one could also assume based on the documentation that test-mode should not be used.
Can anyone clarify the conditions to properly use the Dwolla reflector to actually see payment activity? I'm looking for all of the required conditions if possible including, for example, if a valid funding source must be setup and verified to use the reflector and see payment activity in the Dwolla dashboard. (or perhaps point me to documentation that addresses this?)
I just recently coded against the Dwolla API and against the reflector service. Assuming you have your own personal dwolla account, you can generate a token to represent you here. Since I'm not sure what language you're using, I'll assume php. It is likely you now have a code snippet like this:
$Dwolla = new DwollaRestClient();
$Dwolla->setToken("<your personal generated token from above link>");
$trans_id = $Dwolla->send("<Your Personal 4 digit pin>", "812-713-9234", 0.01, "Dwolla", "My sample transaction detail notes");
if(!$trans_id) {
echo "Error: {$Dwolla->getError()} \n";
} else {
echo "Sent transaction ID: {$trans_id} \n";
}
Please note to use this code sample you need to replace the 2 values surrounded in chevrons with the appropriate described values. Note: The account you are sending to denoted by "812-713-9234" is dwolla's reflector service.
With this code sample, you will send a penny from your own account to the reflector service. After roughly 10 minutes the penny gets returned to your account. You will get a transaction ID each time it is successful. If it is not successful you will get an error code.
If it helps, I got an error code the first time around with something about a non-valid SSN. It turns out I hadn't logged into my account for a while and I needed to confirm my SSN at dwolla.com, however initially I thought this was some error because the reflector service wasn't setup appropriately (since it's a fake service it wouldn't have a valid SSN associated with it).
My understanding is the reflector service is for purely testing your end of things - not to verify what things look like inside the reflector account as far as transaction line item detail from the payee's perspective. If you look at the send() function in the dwolla API it does specify what all the variables you can pass are (this would tell you the level of data and details the transaction will store).
As for specific error codes you can expect, they are documented with meanings here under the error codes section (expand if necessary): https://developers.dwolla.com/dev/docs/transactions/send
After working with other payment networks it is hard not to make assumptions about Dwolla.
The TestMode=LIVE or TestMode=TEST. One assumption being that a test account would allow you to
complete the entire test cycle. However this is not the case with Dwolla. Here is what I found
that addresses the exact requirements to use the Dwalla reflector account.
1. Developer Account Setup
2. Account must be 100% active and have valid funds
3. TestMode=LIVE
4. Amounts less than 10.00 (if you want to avoid fees)
The Dwolla reflector account has nothing to do with TestMode and trying to set TestMode=TEST output unexpected
results. (compared to other payment networks i've worked with).
The cause, in my case was the funds had not yet cleared (account not 100%) and I thought the reflector account was a test account
because the Dwolla documentation at https://developers.dwolla.com/dev/pages/testing says it is a test account
but makes no mention of the configuration setting of TestMode=Live. A test account you would think would require
test mode / environment.

Virtuemart 2 Order confirmation before payment

I'm using VM 2.0.6 and Joomla 2.5 and the Multisafepay payment gateway.
Whenever a user puts a product in his cart, and clicks on checkout, the user is send to another page completely (Multisafepay's website, so not VM anymore) where he can select his desired payment option - same thing as paypal for example. But, at that time, Virtuemart is already sending an e-mail to the user confirming his order. That e-mail is saying: Thank you for your order blabla, the status of your order is blank..
So, VM is already sending an e-mail before the user payed.
Does anybode relate to this or knows an answer?
VM 2.0.6 is working like this :
when the order is placed that means any one of the shipping and payment method is selected.
and cart have valid data it will create the order and send an email to the user that mentioned
an order has been placed.
You can change
the sending mail section if you need.
One function name with notifyemail (iam not sure the name but it start with notify) in the path:
administrator/components/com_virtuemart/models/orders.php
you can check all your required things like shipping /payment methods are selected before calling this function.
the function should be initiate from cart.php controller in front end.
You can change the point where an invoice copy is sent to the customer in the Store Configuration. Look for Configuration > check out > Default Order Status to send an invoice and make sure you have the Confirmed status chosen.

How can I determine if a Zen Cart customer is logged is as admin in checkout?

I need to find out if a customer (during checkout) is also currently logged in as a Zen Cart administrator. The purpose is for allowing certain actions to be available for an administrator placing an order on behalf of a customer (say, by telephone).
My first idea was to check $_SESSION['admin_id'].
However this does not seem to be set, instead $_SESSION['customer_id'] is.
I think this is because different session names are chosen in the admin and customer areas (zenAdminId vs zenid).
How can I find out if this customer would be logged in as an admin, had they been in the admin area at the same time?
I am working on the checkout step prior to sending off to a hosted payment service provider.
Edit: the merchant is logged in as an admin and is entering the customer's details, which are different to those of the admin account, into the checkout screens. It is a customer-not-present/MOTO setup.
You are correct - $_SESSION['customer_id'] is set. And there's nothing in the customer's table which indicates if this person is an admin. However, if they use the same email address for their customer account and for their admin account, you can look up their email in the customers table with $_SESSION['customer_id'], then match that against the admin_email field in the emails in Use this to look up table "admin."
It is worth noting that if your admin cookie isn't restricted by path SESSION_USE_ROOT_COOKIE_PATH=True that you can simply check for the cookie zenAdminID. You can read the contents of this cookie by querying zen_sessions, the sesskey being the value in zenAdminID.
You have to base64_decode the value from the result to get the session. It gives a serialised object, although unfortunately you are unable to use unserialize on it. You can load it as the current $_SESSION but this would overwrite your current one.
I simply did this to get the admin_id:
preg_match('/admin_id\|s:1:"([0-9]+?)"/', $admin_session, $admin_matches);
$admin_matches[1] giving the admin id value.