I am trying to create Stripe recipient objects - but no matter what I try I've never been able to get one to come back as "verified." My understanding is that Stripe verifies recipients by checking the name and EIN / SSN fields against a government database. So far as I call tell I'm entering in valid data that should pass the test.
There are no webhooks for validating a recipient - they are either verified immediately upon creating (or updating) a recipient, or they are not verified at all.
Any ideas what might be going on?
Furthermore ... do I even need to verify recipients before making bank transfers? They highly recommend it in the docs - although it's unclear whether it's actually necessary for making a successful transfer.
It takes us a little while to verify EINs on recipients (SSNs are somewhat faster). In the meantime, feel free to send out transfers to these recipients if you're confident they are who they say they are.
Related
not sure if this question belongs here... We are doing a giveaway but we have >30K wallets signed up. We're worried that many are bots. Have you encountered this yet? AND/OR does anyone have a solution to check each wallet transaction history to see if they have any transactions across other signed up wallets? We checked Algo Explorer and it seems that most cases there's a parent wallet and they're sending from the main wallet to a bunch of sub-wallets... thoughts?
Unfortunately there is no good way to prevent this unless you had some form of KYC. I could have a bot create fresh wallets with no transaction history that would be impossible to correlate with each other. Then if those wallets got an asset from you I could then just have them send that asset to the "main" wallet.
You could also set a minimum value of ALGO required to hold in the wallet to be eligible. It wouldn't completely solve the problem, but would make it more expensive for the people operating the bots at least.
Alternatively, set up a centralized service with email + captcha, make each address owner validate their address via that service and deny if they don't.
How can I have access to bigcommerce's %%GLOBAL_CustomerId%% variable?
I create a sample template and logged in with as a user. That variable doesn't show up. Isn't it suppose to be a Global variable?
Background: I want to create an app for bigcommerce that can identify a user base on their customerID. If I can't grab that variable, you guys see any other way to work around this?
It's not immediately clear in the docs, but you can use %%GLOBAL_CurrentCustomerEmail%% anywhere on the template to get the email address of the currently logged in user.
If you need the customer's ID, then you can query the API with the email as a parameter.
Personally, I'd rather "trust" the customer's email as a point of identification, because you never know if the Bigcommerce ID's may get changed or not (example: Customers are deleted and then reimported, now having brand new ID's).
On a subject of security though, you cannot trust client side data, and should attempt to mitigate fraudulent requests through the use of a CSRF token or some similar measure. Otherwise, anyone can send you an email address and receive back a list of that person's favorite products -- golden information for say, a targeted advertising company, or just your suspicious next-door neighbor Joe who seems to always be conveniently checking his mail right when you get home from work, but never says anything when you walk by, not even a wave or a smile, despite the fact that you all have been neighbors for quite some time now. Like, should I say something? Hahaha, I kid I kid.
I am creating an API endpoint which takes a customer order, create the order and send email notification. At our current design once we successfully create the order, we send a success notification 201 to client and then make a call for our internal email api. Upon getting success notification from us the client app shows users a message to check his/her email.
I don't feel comfortable with this design because if for some reason the email sending method failed there are no way for client to understand this. On the other hand if we wait for to successfully the send the email and then send client app success notification it takes longer times.
So what is the right approach for overcoming this problem?
I think your design works. Why would the client care if the mail service is not working? If the order passes all validations on the server and is persisted I would treat that as a successful state and return 201 Created.
When the client gets 201 Created, then do what you say; give the user a message about checking their mail, but tell them that they should have some patience. Something like:
Your order was submitted. Please check your mail. If you haven't got a mail in 24 hours please contact us, "or whatever other solution here".
You have no control on what time the mail will arrive at the users mail box anyway since mail sending is not a synchronous process.
Remember: Seperate your conserns.
202 Accepted would usually be the most appropriate response for a request which requires further processing. In your case, however, this might not be right because the email is not fundamental to the resource creation.
201 Created is perfectly acceptable for you because the order has actually been created. However, as the spec says, you should return a Location header with the URI of the created resource and an entity describing how to access the resource. That should get around your issue with a mail service failure - the client can still access their order and, to be honest, e-mail is not guaranteed delivery so I'm hoping that the email isn't an absolutely required part of your business process.
Problem Background:
I have a 35K+ user members and growing fast. I am planning to migrate to Amazon SES service. Amazon SES has a criteria to reduce the quota or even terminate service based on bounce-back emails.
I send promotional emails to my members. But the fear is that there are email address which are no longer exists so a fair possibility that Amazon SES notice me and take action to reduce or terminate my service. I need to make sure I have valid email address which do not disturb SES.
Possible Solution:
To cope this problem I am planning to do the following procedure for each email address;
Step1. Collect the MX record for the email domain.
Step2. telnet to that MX domain
Step3. Verify email address with the following pattern
EHLO my_domain_name
MAIL FROM:<my_valid_email#my_domain_name>
RCPT TO:<email_to_verify#my_user_email_domain>
I will verify the response after each command trigger such as email is valid if I receive 250 status after RCPT command
Now what are the possible precautions I should care about to be not marked as SPAM or rejected by the remote server???
I guess you have seen this question here: How to check if an email address exists without sending an email? ? That talks a bit about the disadvantages.
I am no expert but I suspect that it is going to be pretty hard to guarantee that someone won't blacklist you at some point or that you get 100% accurate results from this, or any other method for that matter.
For your scenario though, maybe that does not matter too much - just try to do the check infrequently so that you reduce the number of guaranteed bounce backs and if you send only a few that get bounced back it won't matter too much. On top of that you can have your own system that handles a bounce back and makes sure you do not re-send to that email again.
Doing all of that may be just "good enough" to work.
You may get very different answers from what you expect. Many (most?) e-mail systems set up to prevent spam won't give away user information just like that. My own server, for example, will say 250 OK for every address on my domains, even if those addresses are in fact non-existing.
What you should do is have a system which reads those bounce e-mails and remove unused addresses after a number of bounces. A good way of doing that is having different sender addresses for each message (or at least for each recipient), making it easy to connect bounce messages with their intended recipients. This technique is sometimes called Variable envelope return path.
I'm looking to implement an SMS authentication for one of my projects, basically before a user is able to register an account with us, we would like to authenticate the user by sending sms containing a code to his mobile phone, and get him to put in the code in our form before he can proceed.
I've been looking around and found onVerify to be a pretty good way to go
http://www.onverify.com/
But I'd like to know if there're any other alternatives similar to onVerify as it is a bit expensive, so if I could go with cheaper one, that'd be great.
Thanks!
You can do this easily enough if you have access to an SMS provider.
Typically you send an SMS to the user by making an HTTP request, containing the verification code. You'd store this code, and the recipient number, in some persistent database, against which you can compare when they fill in the details on the form.
You don't mention which geographic regions you expect your users to be in, which can be important given the variable delivery quality in some markets.
Have a look at the HTTP API for BulkSMS, message pricing and coverage.
Note that you can register in various regions, if you, for example, want to price in USD.
Disclosure: I work at BulkSMS