I just started an integration using drop-in components and am trying to prepopulate the email and first and last name and company fields. I saw on couple of places in the docs/articles that you can add the attributes to the component tags like but that seems not to populate the email field.
Is this what the attributes suppose to be doing, since I am not finding any documentation on this? Is there another way to prepopulate the fields?
1 Like
Hi @urbangrz! Thanks for pointing this out. We can definitely add this capability to the components. Can you tell me which one you are using, so that the team may start on that one first?
Hi @kmoreira thanks for the quick response. I am using the dwolla-customer-update.
Has this been implemented yet?
Hi @grogreener!
Yes – this has been implemented! You should be able to pre-populate all of the text input fields in the drop-ins.
Here’s an example:
<dwolla-business-vcr firstName="Jane" lastName="Doe" terms="www.yourterms.com" privacy="www.yourprivacy.com"</dwolla-business-vcr>
1 Like
Looks like the implementation is broken…at least in the sandbox. When you preset any of the fields (fname, lname, email), the validation throws an error. Even if you go and update or change the field, the error remains.
Hi @grogreener – would you be able to share the script tag you’re using to import dwolla-web.js?
It is a react.js app. In the public index.html I have:
<script
type="text/javascript"
src="//cdn.dwolla.com/v2/dwolla-web.js"
></script>
The code for the page is here:
import React, {useState} from "react"
import axios from "axios";
import Box from "../../UI/Box/Box";
const dwolla = window.dwolla;
export default function({customerID}){
const [startDwolla, setStartDwolla] = useState(false);
const [customer, setCustomer] = useState({})
dwolla.configure({
environment: "sandbox",
styles: "/styles/update-custom.css",
token: (req) => axios.get("http://localhost:8080/auth/banking/dwolla/token?action=customer.update&customerID="+customerID).then((res) => {
let token = res.data.token;
setCustomer(res.data.customer)
return {token: token};
}),
success: (res) => axios.post("http://localhost:8080/auth/banking/dwolla/customer", res),
error: (err) => Promise.resolve(err),
});
if(startDwolla) {
return (
<Box>
<div class="customer">
<dwolla-customer-update
customerId={customer.id}
firstName={customer.firstName}
lastName={customer.lastName}
email={customer.email}
terms="www.yourterms.com" privacy="www.yourprivacy.com">
</dwolla-customer-update>
</div>
</Box>
);
}else{
return (
<Box>
<p>In order to buy or sell credits, you must verify the entity which you will be transacting on behalf of.
You will also need to certify that you have authority to transact on behalf of this entity.</p>
<div>I understand and am ready to proceed:</div>
<button onClick={()=>{setStartDwolla(true);}}>Verify Entity</button>
</Box>
);
}
}
Thanks @grogreener ! Try using v2.1.8 of dwolla-web.js and see if that gets rid of that error!
<script type="text/javascript" src="//cdn.dwolla.com/v2.1.8/dwolla-web.js"></script>
The form is already pre-populated with the user’s existing information that is pulled from the API, so you wouldn’t be able to override that with the above code. If you’d like to create a Business Verified customer on behalf of the user, you might want to explore doing it via the API rather than using the drop-in. You could still use the drop-in to handle the retry or document state where you’d want the user to correct their information and/or upload a documentation to verify their business.
1 Like
Thank you – In addition, on both the dwolla-customer-update and dwolla-customer-create, when you prefill any of the names and email address, then the “Agree and Continue” button does not become clickable. The user would have to go into each prefilled field and make a change to the existing data (i.e. delete and retype the last character). Can that be fixed?
Hmm…I wasn’t able to recreate on my machine with the Drop-ins example project. Maybe try using the explicit version 2.1.8 and see if that changes this behavior. I’d also recommend checking out the examples repo I just linked above for some working examples!
If that doesn’t help, let us know!
Is the feature 100% complete? There is no documentation concerning with attribute names to use to set default values. The only values I can get to work are firstName, lastName, email. I need access to them all (address1, legalBusinessName, city, state, etc.) and even non-text fields would be useful
EDIT: though right now manipulating shadow-dom directly works for me
I can also confirm @grogreener issue, pre-populated fields still require user to go through and make a change before the submit buttons appears
Hello @shreya
I have pre-populated email field while creating personal verified customer. Now I want to disabled email field. Is it possible? Please help here.
Hi @sanjay-cygnet – while some of the fields in the drop-in components can be pre-filled, they cannot be disabled.
Thanks @shreya
But in my use case, I have to pre-populate email address that verified at the time of signup in our application. So I have done it, but also I won’t allow user to change pre-populated email address, because if we allow him to change then it may possible customer can enter unverified email.
Please share your suggestion how we can manage this case?
I see your concern. The API does support the ability to update just the email address after the fact. So, if the email address they entered doesn’t match what you have on file, you can call the API silently to update the email address using the endpoint for updating a Customer - Update Customer | Dwolla API Documentation
Hope that helps!
We can do, but the customer face bad experience as he entered different email and we are updating silently.
Actually, you should be able to override the “email” element and hide it from the UI, like so.
.dwolla-customer-email {
display: none;
}
Alternatively, you could try adding a disclaimer/info/alert before loading the drop-in component asking the user not to edit the email address field.
Okay, You mean I need to pre-populate email field and hide email field by CSS. Correct?
But if customer is technical then, he/she can remove the CSS by inspect element and he can edit the email address.
That’s correct. Since the email field is required, it will still need to be populated before calling the API even thought it is hidden in the UI.
I would suggest adding a note/disclaimer for the user to not use a different email address than the one that is already verified and on your file.