According to plaid docs, plaid does not support auth for 10% of bank institutions.
Is there a way to test this on sandbox environment?
Yes, there is! There is a document with all the details on the Plaid site Testing all Auth flows.
The full support version of Auth, that works with 90% of banks, is called Instant Auth. The other flows are called Instant Match, Automatic Micro-deposit Verification, and Same-Day Micro-deposit Verification.
To test Instant Match and Automatic Micro-deposit Verification, you use the test institution Houndstooth Bank and then pick specific test accounts as described in the article. I recommend just reading the article because it has all the details, but here's the summary version:
For Instant Match:
Search for “Houndstooth Bank” in Link.
Enter user_good and pass_good in the Credential pane.
Select the second account that is returned: Plaid Savings (****1111).
In the Routing number input, enter: 021000021 or 011401533
In the Account number input, enter: 1111222233331111
For Automatic micro-deposits:
Search for “Houndstooth Bank” in Link.
Enter user_good and microdeposits_good in the Credential pane.
Select the first account that is returned: Plaid Checking (****0000)
In the Routing number input, enter: 021000021 or 011401533
In the Account number input, enter: 1111222233330000
Enter your legal first and last name.
Select personal as the account type.
Link will display the Automated Micro-deposit success view – click continue to trigger the onSuccess callback with a public_token.
The micro-deposit verification will automatically succeed after twenty-four hours. To test a failed micro-deposit, or to skip the twenty-four hour waiting period, use the /sandbox/item/set_verification_status endpoint to manually control the Item's micro-deposit verification status.
For Same-day Micro-deposit Verification (this is the flow for banks that really can't connect to Plaid):
Search for an institution, and scroll to the bottom of the search results, click on connect your bank manually.
Select “checking” or “savings” as the account type.
In the Routing number input, enter: 110000000
In the Account number input, enter: 1111222233330000
Link will display the success view – click continue to trigger the onSuccess callback with a public_token.
To verify the deposit, call /item/public_token/exchange with your public_token from the previous step to receive an access_token.
Call /link/token/create and provide the access_token from the previous step to receive a link_token.
Open Link with your link_token.
In the first deposit input, enter $0.01
In the second deposit input, enter $0.02
Related
I am designing a website that accepts payment through simple PayPal or Stripe buttons, but also has a section that pays out users through PayPal. What is the best way to do this?
Current setup: The user builds up coins through an action (NDA won't allow me to discuss in detail) and when their coins reach a certain amount, they can cash out in real $. I have designed this flow: Pay Me Now Button -> Screen with PayPal email address input. Repeat email for typos, then Confirm Button -> Success screen
However, the client would prefer a direct link out to PayPal instead of manual input of email addresses. The reasoning is that they would prefer it being arranged through PP's service to reduce manual errors and typing out. As far as I am aware the only way to get paid is through writing down an email address/phone number. I have researched PayPal.me buttons but it still isn't making sense. Maybe there's another service altogether that I can suggest to the client for paying out users in a no-friction way?
I'm looking at how user testing sites pay people, but not getting very far.
If the money is in your client's PayPal account and they wish to send it to a user's email address (that may or may not have a PayPal account already), this can be automated with PayPal Payouts.
If the user does not have a PayPal account already they will receive an email notification and have 30 days to create an account or add the email to an existing account. If they don't, the payment will be refunded automatically.
We faced with testing problem on the side Google Pay.
At the current stage, we get into the GPay only after Card registration on the side of our site, when after filling out the form user is redirected to the GPay page to create a new Card.
A Card is being created : we see it with the data that is entered into the form, but the GPay doesn't send any requests to our site. A special test environment from GPay is needed?
Google Pay's support service asks: "Are you receiving the POST from GPay when you attempt the enrollment flow from the app?"
How we can apply from GPay if we can't create a Card from GP at this stage?
The process of creating a Card is described in paragraph 1 (on the site side).
How to get into the GPay for enrollment at the testing stage?
Support service writes "When you submit your user details from GPay, it sends a POST request to your server so that when your page is displayed it contains the information from the user data form. "
As we pointed, at the current stage we can't send data from the GPay.
It was expected thatGoogle Pay's support service send a POST request to our site, but we don't see POST request's body. It is empty.
Therefore, we asked earlier, What internet service we can see it with?
They answered, as we understood, that we can see it by sending from GPay.
How to send it from the GPay, if at the testing stage we can only see
newly created cards and we don’t get any requests from GPay?
Is testing take place from GPay app?
If so, why don't we have an access?
We get a request POST, but with an empty request body.
The GPay has a lot of users with the Loyalty Card.
Someone has already come across this.
We didn't find such situations on the Internet.
How anybody have handled situations like this before?
How to create a new Card from GPay and see a POST request?
We do not have access to the class settings in the account. On Russian language, we do not see the callback feature, and on English technical support sends to us a screenshot - there are settings in the account. Could there be access rights issues?
To accoding with your link from paragraph 5 https://developers.google.com/pay/passes/rest/v1/loyaltyclass#discoverableprogrammerchantsignupinfo - we did not find the insert barcode /manually settings. Can you tell us where to find them?
At the moment, we can scan the barcode in GPay app(due to help of GPay support service ), but we do not receive a Post request after inserting bar code in GPay app.
Our Russian account settings looks like:
GPay support service see our account on English so:
We don't see these settings for barcode.
In accordance with the documentation https://developers.google.com/pay/passes/guides/overview/how-to/use-callbacks, we set up a callback feature, but we do not receive a post request in the format json (php):
$responseJson_str = file_get_contents('php://input');
$responseJson = '[' . $responseJson_str . ']';
$response = json_decode($responseJson, true);
var_dump( $response);
$file_server = "server_calback.log";
$fw = fopen($file_server, "a");
fwrite($fw, "POST " . var_export($response, true) . "\n");
fclose($fw);
What is wrong?
I show a screenshot with the request POST to our site
https://itcrk.icu/testcallback.php
from https://reqbin.com/
At the beginning of testing stage, we implemented signin / signup as you indicated in points 1-6. We did this functionality was not because we needed it, but thought that it was necessary for testing.
Then we wrote in support team that we need a barcode/manually, as users of other cards are used to. We were answered that we need settings in the account, we did not find them. Support team helped us to configure the barcode in the account of the Merchant Center - Google.We insert barcode in the GPay , but we don’t get json on the site. We assume a problem with access rights in the Merchant Center - Google. How do other cardholders usually set up a barcode in their accounts? We do not have access to the settings n the Merchant Center - Google, unfortunately. Support team writes that there should be access, but it does not.
It turned out that there are two ways to work with cards in the GPay. The first method is described in the documentation here https://developers.google.com/pay/passes/guides/enrollment-signin, the second method is to scan the card(barcode/manually) and use it as a card storage, but card data is not sent to the user’s server.
The Loyalty card is simply displayed in the GPay with its number(from barcode/manually) and that's all.
Sign up and enrollment are triggered from the google pay app: https://developers.google.com/pay/passes/guides/enrollment-signin
You will see post once a user goes into the Google Pay app and hits add pass then finds your program and hits sign up/ sign in.
See 1-2.
You have to use the account you provide to support team - its only visible for them for testing.
It may not be from Google. Google requests have the body with the user details.
Go to google pay app and sign in with user that is whitelisted by support to see the program. Hit add pass, then loyalty program then search for your program then hit sign up/ sign in and it will post to the endpoint defined here: https://developers.google.com/pay/passes/rest/v1/loyaltyclass#discoverableprogrammerchantsignupinfo
Let me also clarify enrollment and sign in. This is what a user sees, what the Google Pay app does and finally what a merchant needs to do:
Google Pay user navigates to passes tab in Google Pay App, hits "+ Pass":
Google Pay chooses which type of pass to add, hits loyalty for this example:
User searches and presses on the specific program they want to sign up for (theres a testing phase before it goes public, in which only accounts which you tell support team can see the program in google pay app):
User then fills out information to share and consents to share their information with this merchant, then they press continue.
Google Pay Then does a POST request with user info to endpoint defined here on the loyalty class by merchant: https://developers.google.com/pay/passes/rest/v1/loyaltyclass#discoverableprogrammerchantsignupinfo
Here is where merchant, yourself would have to be listening for POST to endpoint you defined in the setting mentioned previously and give user form to finish providing all details needed and then redirect to the JWT link to automatically save the pass.
See https://developers.google.com/pay/passes/partners/enrollment-signin for reference.
It turned out that there are two ways to work with cards in the GPay. The first method is described in the documentation here https://developers.google.com/pay/passes/guides/enrollment-signin, the second method is to scan the card(barcode/manually) and use it as a card storage, but card data is not sent to the user’s server. The Loyalty card is simply displayed in the GPay with its number(from barcode/manually) and that's all.
I am using auth0 in my existing regular php web application.
I have free as well as paid users in my site. For free users registration process is simple, I call the create user api which triggers the verification email.
But for paid users I have a multistep form. In first step users enters his information and registered as a free user in application then redirected to payment page. I can not call auth0 reg api after first step as user will get immediately verification email before payment.
If I call it after successful payment then its impossible to track if user bails out(Doesn't fill payment form, but already registered as a free user).
Please suggest what approach I should follow.
Thanks in advance
Make sure that you disabled public signups (this endpoint) and instead are performing the registration of users from your backend through the Management API create user endpoint.
Then you can use the verify_email parameter to indicate that a verification email should not immediately be send after user creation. You could then later use this endpoint to trigger a verification email to be sent after the payment form is completed.
If you have want to achieve best result i think you must follow below step to get rid of this problem:
1. Remove public signups in your application by trying this authenticating signup.
2.Perform the registration of individual user by this way create user's
3.Now you can simply use the verify_email parameter.
This parameter can be easily use post verification email process which prevent the issue of signup/signin before making payment.
Hope you got it & feel free for any help.
My boss is setting up a UK PayPal account for use with REST API for direct credit card payments and payouts.
During this process he's been asked to choose between signature and certificate credentials.
However as far as I understand the REST API uses OAuth 2.0 so what we need is an ID and secret associated to an App.
How should we proceed?
Setting up your credentials for REST is done on the developer site https://developer.paypal.com/. You are correct that the choice between "Signature" and "Certificate" is irrelevant in this case. Try the following:
Go to https://developer.paypal.com and log in using the email address and password of the live PayPal account that will be receiving payments.
Click on “Dashboard” up at the top of the page. You should see a list of your apps here. (If, instead, you see a sentence that says “Create your first app to view it here”, you will need to create at least 1 app)
Click the app name. You’ll see your client ID and Secret for the Sandbox. Toggle your view to “Live” in the upper right corner of the page to see the credentials for the live environment.
You can click on “Account Eligibility” to see what features are available for Live. If the feature isn’t already added there will be an “Enable” link to the right. Clicking on the link will start the request process for that feature.
I have created a nice little login script for my website that lets users login with Facebook or Google at the moment.
What I am trying to do is set some checks to make sure that duplicates do not appear in the database.
Here are some scenarios I have covered :
Login with Google/Facebook account and I have already registered this account, This will log the user straight in as they have already linked this account.
User has already registered with Google account, yet clicks Facebook because they cannot remember which account they used. This will alert the user that the email address returned from Facebook has already been registered with a Google account. This will enable them to click on Facebook to Login ??? NOT SURE ON THIS LOGIC AT THE MOMENT ???
User clicks on Google/Facebook to login, yet the email address returned is a user that went through the manual registration. This will alert the user that the social account they are trying to login with will require a password.
What I am thinking of doing is allowing users to LINK ACCOUNT so that the alerting process does not happen because I can link my facebook account to my google account through my website, and vice versa etc etc.
What I am asking :
Are there any other checks I may be missing? Is this logic sound? Is there anything I am doing which makes you question the login process??
Basically asking logic advice on this one.
Well congratulations! You're almost on the right track. Let's breakdown your situation here.
Ideal Situation
1. Registered on your site
2. Log in with Google
3. Log in with Facebook
Now, let's take the common denominator here, I mean the primary key. I am guessing in your case it should be the email address.
Actual Process Flow
1. User registers. You save the email address
Or,
2. User registers with Google/Facebook and you save the email address.
Login Procedure
1. You receive the email address either from direct login/facebook/google.
2. You match it against your table
3. On positive match, you link this social login to an existing account
If,
4. It is not a positive match then you accept whatever data you receive and then forward
and then pass on to the registration page.
Hope this helps! Let me know if you want to know anything else.
Cheers!