Dwolla reflector off-site test account and Payment Activity - dwolla

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.

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.

Debugging a zero-transaction result from the transactions endpoint in customer data api

We use the https://financialdatafeed.platform.intuit.com/v1/accounts/account_id_goes_here/transactions endpoint on a recurring basis to fetch transactions for all of the accounts we sync. We've been using this stably for quite awhile now, across a wide variety of accounts spanning 100s of financial institutions. This works great.
However, occasionally we get a report from a user who claims that we're not receiving transactions that they know to exist. Our investigation protocol is as follows:
To ask the user if they see the transactions when they sign into their bank's web site directly
To ask them to confirm that the credentials they used on their bank's web site are precisely the ones that they entered when setting up credit card sync on our site
We then manually inspect the response body from the above mentioned URL, to make sure that the HTTPS response indicates HTTP 200 and has a non-error response body (our app catches these errors correctly, but if debugging mysteriously missing transactions, we inspect the response body visually).
We look to see whether we're successfully syncing transactions for any other user that relies on the same FI. If we are, we become confident that both the bank and Intuit APIs are well-behaved, and that the problem is on our end somehow.
We sometimes ask users to try the same FI in Mint, guessing that if it fails in Mint, that it might be a bank or FI issue.
Investigation steps 1-2-3-4-5 tease out the root cause of at least 99% of the times when a user emails us to say that we're not successfully receiving their transactions. However, the remaining 1% are the tricky ones.
Today I'm faced with a situation where a user sees the txns on their bank website, swears that they are using the same creds when adding the card to our site, the HTTP response from the endpoint is HTTP 200 but contains zero transactions, but yet when the user tries via Mint they successfully see transactions.
However, the particular FI (OnPoint Community Credit Union) is not one where I can do investigation step 4, because we have no other users that currently rely on that FI. Is it possible for someone at Intuit to check to see whether there is evidence that users relying on OnPoint Community Credit Union are currently, successfully, retrieving transactions from that particular FI?
Any other suggestions for how to further deduce whether the zero-transaction response is due to: (a) user error, (b) bank server responding incorrectly, (c) Intuit server responding incorrectly, vs (d) our app behaving incorrectly?
Can you please submit a support ticket to Intuit with the Account_ID that is missing the transactions so that we can diagnose the issue? The first place to start when diagnosing the issue is to look at the Agg_status_code to make sure that reflects a '0'. If we are unable to login due to invalid credentials or MFA might be a cause of the missing transactions. I can help diagnose though once a ticket is submitted.

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.

PayPal (Payflow Pro) Error 52

I am trying to set up a test process to get some authorizations completed. I managed to get a response other than Invalid Vendor (I had set up the account wrong), but now we get this response:
RESULT=52&PNREF=XXXXXXXXXXXX&RESPMSG=Insufficient permissions to perform transaction
Any thoughts on how to correct this? Request string:
TRXTYPE[1]=A
&VERBOSITY[4]=HIGH
&ACCT[16]=411111XXXXXX1111
&TENDER[1]=C
&AMT[4]=1.99
&CURRENCY[3]=USD
&USER[8]=MyPayFlowUser
&VENDOR[8]=MyPayFlowUser
&PARTNER[6]=PayPal
&PWD[10]=XXXXXXXXXX
&ORIGID[13]=XXXXXXXXXXXXX
You should have API_FULL_TRANSACTIONS. Result code 52 usually means you are trying to make a Payflow API call when you only have a Payflow Link account. Payflow Link accounts are only allowed to make an API call for the SECURETOKEN.
Without more details and looking at the account, it is hard to say what is happening. If I had to guess just based on these details you provided, it sounds like you do not have permissions to perform the type of API call that you are trying to. If you can provide the PNREF number for the transaction I can take a look at it on my end.

Has anyone had success using PayPal SoftDescriptors?

Paypal provides access to a parameter called "SoftDescriptor" in a number of their payment request API calls, in the classic API (either NVP or SOAP). In theory, this parameter lets you send transaction-specific data along with your request, which will be passed along to the buyer's credit card statement.
This parameter is available on at least:
DoCapture
DoReferenceTransaction
DoExpressCheckoutPayment
I cannot, for the life of me, get this to work. None of these calls seem to set the softdescriptor for the initial descriptor (Which shows up in the bank statement while the charge is pending, before the payment posts). I've been waiting a few days for the payments to post to see if it will change at that point, but I'm skeptical.
Has anyone successfully used the SoftDescriptor? Did it require extra account setup?
This might be very late.
Soft Descriptors is supported only for US,UK and CA merchants.
Your account needs to be enabled for Soft Descriptor.You can contact Businesss/Customer Support to get this enabled.
https://developer.paypal.com/docs/classic/release-notes/merchant/PayPal_Merchant_API_Release_Notes_115/#softdescriptorforpro
Sorry, I know this is an old post, but I was looking for the same answer to the same question and I thought I would share what I found.
You should be able to use the following link to move past this error. In my case, I had a comma after the wrong right curly brace. Just copy and paste the example, in the aforementioned link, and change the values to meet your needs.
And I am about to post my own question about why the transaction amount is considered invalid