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.
Related
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 .
After I've logged into developer.paypal.com, and access Applications/Sandbox Accounts, and click "Create Account" to add personal users to my sandbox accounts, I get the error message seen below. The total records increments, but the additional accounts don't display, and I can't log back into the Sandbox using the credentials I've created.
Anyone have an idea as to what's the issue?
I had this problem, and also needed to put in the fields for 1st and last name, which the Test Account create form says are optional. So, password needs to be complex, amount needs to be in there, and first and last name need to be specified for this error not to be thrown.
Try entering Paypal balance value between 1 and 5000 while creating a test account. I too had the same issue and this is how I resolved it.
PayPal balanc: While this field is optional, it’s a good idea to
create test accounts with positive bank balances. Enter an integer
value between 1 and 5000.
Source : http://believeinmiraclesx.wordpress.com/2013/03/15/paypal-sandbox-were-sorry-but-something-went-wrong-please-delete-this-account-and-try-again/
For me, it seems this issue was caused by password validation. Try using a more complex password.
I'm using the callback API to prevent someone selecting a non-UK shipping address. I've supplied a callback url, I've set CALLBACKVERSION to 61.0.
When I go into the sandbox and choose an address I know the callback page is being called as I've added code to email me the values submitted to it and the value returned to PayPal. For anything with a SHIPTOCOUNTRY that isn't GB the response is
METHOD=CallbackResponse&NO_SHIPPING_OPTION_DETAILS=1
I've also tried setting a fuller response in case it doesn't like some required field to be missing
METHOD=CallbackResponse&CURRENCYCODE=GBP&L_SHIPPINGOPTIONNAME0=Standard&L_SHIPPINGALABEL0=Standard&L_SHIPPINGAMOUNT0=2.95&L_SHIPPINGOPTIONISDEFAULT0=true&L_SHIPPINGOPTIONNAME1=Express&L_SHIPPINGALABEL1=Express&L_SHIPPINGAMOUNT1=5.95&L_SHIPPINGOPTIONISDEFAULT1=false&NO_SHIPPING_OPTION_DETAILS=1
But it's still allowing non-UK addresses and just using the shipping options set during the initial set up request.
Any suggestions on where I'm going wrong?
After opening a ticket as suggested by PayPal_Patrick the problem was that I was adding the callbackversion in the wrong place. The full response to reject a shipping address on callback is:
METHOD=CallbackResponse&NO_SHIPPING_OPTION_DETAILS=1&CALLBACKVERSION=61
There are different transaction ID's for Buyer and Seller accounts.
I think this might be an issue caused by the country associated with the buyer account being used. I'm going to reach out to the product team for Express Checkout and see if it is intended functionality or not - I don't believe it would be.
If you want to stay updated on the issue I would recommend creating a ticket to PayPal.com/mts, give me the ticket number, I'll grab it and keep you involved.
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.
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.