If I combine guestSend and registerUser into a single <form>, will that user's bank account be immediately verified after that?
Would this prevent me from having to call verifyFundingSource(), i.e., 3-5 days waiting for Dwolla to sync up with the bank?
The Guest Send feature will not verify a bank account for a Dwolla user. You'll always need to wait for Dwolla to verify a new funding source for an account - there's no way to bypass that, unfortunately.
Related
I am after the best practice for handling incomplete stripe connected account onboarding.
When onboarding goes smoothly, everything is simple. But there are fiddly edgecases everywhere, which results in a lot of permutations of values for account requirements
These include
current_deadline
currently_due
disabled_reason
errors
eventually_due
past_due
pending_verification
This creates a lot of complexity.
I need a simple way to:
figure out if the connected user needs to be notified of something (i.e. that they need to give more info), and
what to tell them.
My current strategy is to check if errors is empty, and if not, simply display them along with a link to manage the user's stripe account so they can address the errors.
But I'm worried this strategy will miss things (perhaps minor things that could be addressed before they become errors).
TL;DR I suspect most users will onboard without any problem, but for the few who do have issues, I want to ensure the app notifies them that they need to address them. What is the best way to do this? (using the information in requirements or other info)
When handling identity verification manually using the API, a simple way to check whether your connected user might need to be notified to provide more info is to look at the charges_enabled and payouts_enabled properties on the user's account object. If either of these two properties are false then you might need to reach out to the connected user for more information.
In cases where the connected user's charges and payouts are disabled, you would use the disabled_reason property on the requirements hash to learn the reason why charges and/or payouts are disabled. The possible disabled reasons are all documented here, but I'll list them out nonetheless:
action_required.requested_capabilities You need to request
capabilities for the connected account. For details, see Request and
unrequest capabilities.
requirements.past_due Additional verification
information is required to enable payout or charge capabilities on
this account.
requirements.pending_verification Stripe is currently
verifying information on the connected account.
rejected.fraud Account is rejected due to suspected fraud or illegal activity.
rejected.terms_of_service Account is rejected due to suspected terms
of service violations.
rejected.listed Account is rejected because
it's on a third-party prohibited persons or companies list (such as
financial services provider or government).
rejected.other Account is rejected for another reason.
listed Account might be on a prohibited persons or companies list (Stripe will investigate and either reject or reinstate the account appropriately).
under_review Account is under review by Stripe.
other Account isn't rejected but is disabled for another reason while being reviewed.
Using the disabled_reason, you can assess whether the user needs to be notified with a request for more information (i.e., requirements.past_due), whether they need to be notified for another reason (e.g., rejected.listed), or whether you need to make programmatic changes to the user's Stripe account (e.g., action_required.requested_capabilities).
We're just a few weeks away from releasing our custom built SaaS app for Freight Brokers and (eventually) Carriers. We're deciding how to handle failed credit card payments. The options have so far been:
Immediately restrict their account and require a payment. Send them an email saying an Admin can login and restore account access
or
Give them 7 full days to pay(including weekends), send them an email when the payment fails, a day after and 2 days after the second email. Then send them an email when their account access has been restricted. When they login, they can pay, but the payment would include the days used without payment.
I'm leaning towards the second one, because if I were a business owner, i would not want to come in and my employees are sitting because none of them have a company credit card to pay for the software.
Thoughts?
EDIT: Lmao I spelt "handle" wrong in the title... Fixed.
You can configure Stripe Dunning process which facilitates you to handle failed payments in a better way for subscription base billing.
Its basically enabling retry schedule with customize timeframe. you can cancel the subscription or mark the subscription as unpaid after all retry attempts have been exhausted. There is a webhook which indicates the transaction details, using that you can handle your business logic like hold the tenant or delete the tenant.
in our application we allow users to link card to their profile and use it later for payments inside our system. Recently we had a couple fraud attempts when users added stolen credit cards (so they knew all information about card, including CVV).
The only thing that we came up with is to make temporary payment of some small random amount so user can check bank transactions report and verify ownership by providing exact authorized amount.
Is there any other common proven ways to verify card ownership?
Yes, there are a couple of things you can do at the very least:
Validating the house number and postcode/zipcode provided to you with the result returned to your from your payment processor on the pre-auth (AVS - Address Verification Service).
3D secure verification (Mastercard SecureCode or Verified by Visa) - the user is redirected to their issuer's site (or one ran for them by e.g. Arcot) and has to enter a secret only known to them.
Validating a small random amount is also a good check to make, however this takes a few days whereas the above can be validated instantly.
If so, are there additional API calls that need to be made from the one's listed in addFundingSource in order to have both under a single Dwolla account?
At the moment I have no way of generating both account types so I can't provide code, but obviously it would help to know if this is even possible first.
As long as a bank account supports ACH transactions, it doesn't matter to Dwolla whether the bank account is intended for for-profit or non-profit use. You should be able to add both kinds of funding sources to a single Dwolla account.
I think that the Dwolla API sends the wrong transaction ID in notifications. In a normal dwolla money transaction, two transaction IDs are created (this is weird to me, but that's how dwolla does it). Because these two are created at the same time, they are always (in my experience) consecutive numbers.
So e.g. if account X sends money to account Y, Y will see transaction id M, and X will see transaction id M+1.
But Dwolla's notification webhook will send Y details of the transaction with id M+1. While ID M+1 is still unique to this transaction, ID M+1 cannot be used by Y via the API - because M+1 is supposed to only be used by X.
Here is a specific example:
Via my webapp, I send money from my personal dwolla account to my organization's via the off-site gateway api.
My webapp is sent the transaction details in both callback and notification form. The transaction id generated by step 1 is 1431566. This is the transaction id sent to both callback and notification. My web app stores this Id for future use.
Via my webapp, I decide to refund my personal dwolla account from my organization's so:
My webapp tries to query dwolla about transaction 1431566, to get the SourceId, but this fails - dwolla reports "Transaction not found for account". My automatic refund cannot continue without an ugly kludge like subtracting one from the Id and trying again.
The manual workaround is to login to my organization's dwolla account via the web interface. Here I can look for the transaction based on datetime and I can see that the transaction ID is actually 1431565 (correctly reported in the web interface). If I go into my organization's database and replace 1431566 with 1431565, I can repeat step 4 and it works this time. After that I can initiate a send() and the refund goes through.
I reported the same problem here before dwolla moved support to stackoverflow: https://getsatisfaction.com/dwolla/topics/callback_and_webhook_notification_sent_wrong_transaction_id_off_by_one
I figure it will be fixed faster if other people have the same problem. Or maybe I'm missing something obvious and someone will point it out.
Thanks to Michael's help, we were able to get around this issue by using the receiver's OAuth token when getting the transaction details instead of the sender's OAuth token.
For example, say I send some money using the API and transactions 1202 for the money sender and 1201 for the money receiver get created. If you make the API call to get details for transaction 1202 but use the receiver's OAuth token, it will give you details for transaction 1201, including fee information.
I'm not sure if the situation is exactly the same since we are acting as the facilitator between two transactions, so no guarantees that this will work in your situation. But it's worth a try.
So, your application's key & secret can access the transaction ID posted to you by passing the transactionById() method your application's client_id and client_secret, as opposed to the oauth_token. Meaning, when you poll for the transaction, instead of querying this URL:
https://www.dwolla.com/oauth/rest/transactions/{transaction_id}?oauth_token=x
Query this url, instead:
https://www.dwolla.com/oauth/rest/transactions/{transaction_id}?client_id=x&client_secret=y
Makes sense?