Help get this topic noticed by sharing it on Twitter, Facebook, or email.

Sandbox environment

Is there a sandbox environment so developers can test the API without have to move actual money and setup bank accounts ? Thanks.
15 people have
this question
+1
Reply
  • Greetings Moustafa,

    Please be more specific. Which parts of the GRID APIs are you using ?

    A test parameter is built in to the Off-site Gatweay calls.

    All of the REST endpoints can be tested by using URLs matching the following pattern :

    Send Money
    live : https://www.dwolla.com/oauth/rest/tra...
    sandbox : https://www.dwolla.com/oauth/rest/tes...

    Request Money
    live: https://www.dwolla.com/oauth/rest/tra...
    sandbox: https://www.dwolla.com/oauth/rest/tes...

    Seach & Return Contacts
    live: https://www.dwolla.com/oauth/rest/con...
    sandbox: https://www.dwolla.com/oauth/rest/tes...

    Please review the API again & let us know what call you're interpreting as an 'add bank account' function.
    • view 2 more comments
    • I'm developing an app using a combination of java and javascript with AJAX on Google AppEngine. It uses oauth2 requesting Account Information and Send Money permissions only with javascript and a java servlet callback. The oauth token is retrieved without a problem and I am able to get authenticated user information as well as anonymous user info just fine.

      Currently I'm testing Send Money with the https://www.dwolla.com/oauth/rest/tes... endpoint and finding the results less than helpful. Regardless of what I submit, so long as the access token is valid, I receive the same response JSON where SendResult is1000.

      I'm intentionally sending pin numbers that are incorrect, but also used a correct one. destinationId and amount are also present. Although, I should mention the authenticated test account also has a standing balance of $0.00 and I've set a facilitation fee of $0.01 for the time being.

      Based on this server response, I have no idea if what I'm doing is working correctly or how error cases present themselves for any number of problems. What should I expect if a PIN is incorrect? How about insufficient funds? Is there a different endpoint I should be testing with or documentation that reveals the range of server responses I need to handle?
    • You're doing everything right.

      Dwolla needs to improve+++ on what, precisely, the sandbox endpoints as they stand today are intended & capable of doing until a more extensive testing environment is released.

      The test (testapi) endpoints for the REST endpoints only validate the request & access token. That is : "this is a good request that would have been processed by Dwolla as normal".

      You're ready to move on.

      I suggest keeping you're zero balance & do the tests you're doing against : https://www.dwolla.com/developers/end....

      Pass a bad pin , you'll get a very clear error : "Invalid account PIN"
      Then pass the correct pin, again, you'll get a very clear error message : "Insufficient funds."
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned happy, confident, thankful, excited kidding, amused, unsure, silly sad, anxious, confused, frustrated

  • which parameter tells the dwolla server that we are using "send endpoint" for testing purpose ??

    i am using this api
    api_url = "https://www.dwolla.com/oauth/rest/tra..."

    i also sent

    {
    "test":"true";
    }

    none of them worked for me

    This reply was created from a merged topic originally titled
    how to do i test the send endpoint ??.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. happy, confident, thankful, excited sad, anxious, confused, frustrated kidding, amused, unsure, silly indifferent, undecided, unconcerned

  • How do we test our API without passing around "real" funds? Is there a sandbox like function in Dwolla so we can test and ensure the functions are correct before applying API to a live site? Thanks for your time. It is greatly appreciated!

    This reply was created from a merged topic originally titled
    Test a/c to test live payment API details....
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. happy, confident, thankful, excited sad, anxious, confused, frustrated kidding, amused, unsure, silly indifferent, undecided, unconcerned

  • Is dwolla payment gateway have any testing a/c to test the transaction will done which we integrated into the site? For instance, Paypal provides sandbox before putting live credentials of a/c developer can check full payment process?

    This reply was created from a merged topic originally titled
    Is Dwolla provides test a/c like sandbox which paypal have?.
    • view 1 more comment
    • I am trying use "send" action using "endpoint", using this api "https://www.dwolla.com/oauth/rest/tra.... is there a way to test this call with dummy send payments and without actually making any payment(like the way userless registration has an option as "test" parameter) ?.. If so, how do I use the test parameter while calling the API parameter do we have to use ??

      Currently I am sending
      {
      "test":"true";
      }
      as a part of json data which is not working(I am not able to make dummy payments because it says insufficient funds)

      I also tried sending test = true as a part of the URL which didn't work either. I had posted same question before but haven't found any real answer from Dwolla guys. I am trying to be as clear and specific as possible here, please tell me how can I achieve what I am trying to do.
    • How to test this endpoint


      How to test this endpoint is answered in my first post on this topic (above).

      Added Parameters


      These test parameters being added to the REST calls are invalid.

      I believe I mentioned this earlier to another very similar situation where rather than an invalid parameter named 'test' , you were adding an invalid parameter named 'testmode' : http://getsatisfaction.com/dwolla/top...

      Are you sure you have a problem?


      If you're getting errors that say you have insufficient funds & if you do have insufficient funds in the sending account, it seems to me the call (whether you're using the test endpoint or the live endpoint) is performing exactly as expected.

      You'll also notice in my other comments to you at the end of the above link I explain that fake transactions won't actually be created on your live accounts & that the test endpoint is purely a full-validation tool for your request.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned happy, confident, thankful, excited kidding, amused, unsure, silly sad, anxious, confused, frustrated

  • I’m confused
    Karrie, I'm trying to test the REST endpoints using the pattern outlined above and am getting errors.

    Here is the original URL from the dwolla iOS SDK.
    2012-03-08 11:47:36.144 Dwolla Tap[8124:fb03] URL Being Called : https://www.dwolla.com/oauth/rest/acc...

    Here is the modified URL according to the pattern outlined above.
    2012-03-08 11:47:36.144 Dwolla Tap[8124:fb03] Modified URL for Sandbox : https://www.dwolla.com/oauth/rest/tes...

    I"m getting a standard "404 - File or directory not found." error when using the modified URL. Has this changed recently?
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned happy, confident, thankful, excited kidding, amused, unsure, silly sad, anxious, confused, frustrated

  • 2
    The lack of an effective test API is burdensome and unreasonable. Dwolla, as a secure payment processor, should be doing a better job at this. As third party developers, we need an effective means of testing transactions and running unit tests for verification.

    Creating a test account for testing send transactions apparently isn't possible (based on the response I received from tech support). Using the existing test endpoint at https://www.dwolla.com/oauth/rest/tes... is mostly worthless because it doesn't send back the same response as production.

    This means the only way to test is using live accounts, in production, which (when doing negative test cases, like incorrect PIN, etc...) will quickly cause your account to be locked and break any future unit tests. As developers we need to be able to code to, and deal with, any possible response from the server (insufficient funds, invalid PIN, etc...).

    The API is clearly using WCF and .Net, I encourage the developers / management to research the various AOP / dependency injection techniques that exist for dealing with this exact scenario. We should have a test endpoint that precisely mirrors production, except for obvious differences (don't actually process funds, don't disable accounts, etc...).

    As someone who has implemented similar systems of this scale in .Net, I know that implementing this for your development partners is a straight forward task.

    Dwolla is processing financial transactions and providing an API for third parties to do the same, but apparently very little effort has been put in to making sure this API is robust (WCF is notoriously bad at dealing with RESTful APIs, and requires additional attention to detail to ensure smooth integration with developers who are used to less finicky REST technolgies - just browse through your forums and review the endless questions about server faults, application/json header problems, parameter ordinals, etc... to see what I mean). I would not rate this API and development environment as currently suitable for professional integration. I hope to see this change over time, as I consider my options for payment processor integration in the future.

    Dwolla recently updated their documentation, updated the developer portal, and provided a third-party console for testing transactions, but for some reason there still doesn't seem to be an effective test endpoint. In fact, from what I can tell, the test console actually sends transactions to production! Even stranger, in order to use the console, we have to grant full oauth rights to a third party test console for our sensitive financial information! (again, we're apparently not able to create "test" accounts with dwolla).

    How can a company who's core business is to deal with secure financial transactions consider this to be a good idea? When you consider the fact that access tokens don't expire, we're basically handing over the keys to our production accounts to a third party who's primary line of business is API testing. There are significant security concerns there. I wonder if the choice to implement the test console in this way was fully thought out, and all the possible vectors of attack considered. Is this console safe from XSS? XSRF? Session hijacking? Are you sure? Because it looks to me like the function at line 569 of mini_snapshot.js is an XSS attack waiting to happen (note the later straight rendering of uncleansed UI input). These are production accounts it's using...

    Dwolla clearly has a talented design and development staff, so I'm confused about why such a basic and straight forward item, like providing a robust testing environment, seems to be such a challenge for Dwolla to implement.

    Please don't mistake my intent, I'm not trying to bash anyone here. I'm trying to provide constructive feedback that can hopefully be used as a source/motivation for improvement.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned happy, confident, thankful, excited kidding, amused, unsure, silly sad, anxious, confused, frustrated

  • I’m frustrated
    I am trying to understand how a company presenting themselves as a mature financial company does not have a mature full featured way to test out their APIs. This is a request and plea to have a way to test every feature of the API without moving real money around.

    This reply was created from a merged topic originally titled
    Full featured test environment.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. happy, confident, thankful, excited sad, anxious, confused, frustrated kidding, amused, unsure, silly indifferent, undecided, unconcerned

  • @Clay Gulick: I would *love* to have an actual conversation with you. You're obviously very knowledgeable about WCF and pentests. Mind shooting me an email to michael@dwolla.com?

    Listen, the bottom line is that you're right. Our lack of test endpoints is unacceptable. Like many other startups, we are growing quickly, and are understaffed at engineering. We're constantly trying to reevaluate our roadmap and what are the most important things we need to get done quicker. We do believe that test endpoints are very important, and we should be releasing our testing platform very soon. Essentially, it would enable developers to add a 'test' parameter boolean to every method our API offers.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. happy, confident, thankful, excited sad, anxious, confused, frustrated kidding, amused, unsure, silly indifferent, undecided, unconcerned

  • Hi Michael, I reached out to you earlier this week but haven't heard back. Did my email make it to you?
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned happy, confident, thankful, excited kidding, amused, unsure, silly sad, anxious, confused, frustrated

  • 1
    +1 on this. We're considering a large implementation, and lack of a true testing environment is a huge deal to us. I'm very wary of having to do whack-a-mole testing instead of something more structured (ie, unit testing).

    Ryan
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. happy, confident, thankful, excited sad, anxious, confused, frustrated kidding, amused, unsure, silly indifferent, undecided, unconcerned

  • Ryan, agreed.

    Michael said he'd like to discuss this, but I've tried to contact him twice with no response, so I guess he got busy with a higher priority, which is understandable, but I was hoping that I could help them with some of these issues (I was going to discuss the possibility of developing a thin nodejs RESTful proxy to accept/validate incoming requests and broker them over to the WCF stack, both for production endpoints and test, which would provide a much more robust front-end for their API).

    The good news is that he said they are expecting to release a test endpoint soon, so I'm looking forward to that, though I don't think this will solve a lot of the core issues, like the fact that WCF just really isn't very good at REST, and just responds with XML formatted SOAPish error messages whenever it sees something it doesn't expect. Like I said before, it takes quite a bit of work to make WCF behave properly with REST.

    I understand what it is like to be tied to a code base though, which is why I think it would make sense to stick a node layer in front of the WCF stack, and just feed WCF what it expects. Node is great for this sort of thing (IO bound, rather than CPU bound) and deals with JSON/REST API's much more gracefully.

    This would give the clients a clean *real* RESTful API interface, with proper JSON responses to validation problems, plus provide an additional layer of security (the node cluster could sit on the DMZ, and proxy requests to the internal processing server running WCF).

    Alternately, a similar thing could be done in pure .Net, by simply abandoning WCF as the communication layer and doing simple .net http handlers to parse the JSON body and call the internal classes. For RESTful interfaces in .net, I've found this to be preferable to WCF in almost every case. WCF really only shines with SOAP and lower level IP communications, imho.

    Regardless, we (as third part integrators) continue to be severely limited in our ability to integrate with Dwolla.
    • Actually RESTful interfaces are quite easy to build using WCF's new webHttpBinding. The newest version of ASP.NET MVC also has a nice way to build RESTful interface.
    • Agreed - ASP.NET MVC is a reasonable approach with RESTful stuff, but I'm not sure it's better than just using a plain old http handler, doing some basic URL parsing/json serialization/deserialization and feeding your BLL. I'm kind of partial to this approach because it works with pretty much any OOPy language, the same approach can be easily used with Java/Struts, C++/wxSocket/Boost asio, or pretty much any other language/architecture. Heck, I've even done the same basic concept in straight C/asm on a modified IP stack running on an 8 bit AVR ATmega328p talking to a ENC28J60 over SPI.

      I'm not sure I'm sold on the WCF stuff, I've been bitten too many times by WCF and REST (services crashing if params aren't passed in the exact order, heavy reliance on Content-Type headers, poor datatype mapping, extensive configuration requirements, cryptic error messages, and general lack of flexibility). Even though (I agree) webhttpbinding makes things better, my definition of "easy" might be different than yours. Here's mine (node js):

      app.get("/someService", function(request, response)
      {
      response.JSON(dal.doSomethingInteresting(request.body.params[someParam]));
      }

      Compare that to WCF with all the config, attributes, service contracts, etc.. etc...
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned happy, confident, thankful, excited kidding, amused, unsure, silly sad, anxious, confused, frustrated

  • As an update, as of 1/15/2013, I've been told by Dwolla support that the /testapi/ endpoints are no longer accurate. They have put in a ticket to have them taken down.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned happy, confident, thankful, excited kidding, amused, unsure, silly sad, anxious, confused, frustrated

  • hey,

    is there a way to test the API / Off-Site Gateway server-to-server checkout request?

    are there any test credentials i can get?
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. happy, confident, thankful, excited sad, anxious, confused, frustrated kidding, amused, unsure, silly indifferent, undecided, unconcerned