It seems to be a choice between - time and extra work (doing the Child Assessment and then the later Child Resrictions Assessment), or paying money for approved age verification software. I wonder if someone will produce some free age verification software - that would be nice.
I've not really considered if my software is going to be available. Obviously it rather depends on the support burden that may end up producing as I've hardly tested it in anger. As mentioned previously it is not a drop in XF add-on since I was doing it as a spare time project I just wrote it in Ruby (my language of choice) and packaged it as a gem. It's not complicated, but if you were not comfortable using a *NIX shell it's probably not for you. If you are happy with hacking your way around then well I guess we can discuss things!
The verification service I'm using (VeryifyMy) has several potential states for verification:
unknown, approved, pending, failed, cancelled, ignored. In my software these are mapped to XF groups to add users to. In most cases there is no group to add, but for
approved and
failed we do have groups (18+ and 18- in essence).
So the software runs (as a system cron task) and has a look at the active XF user upgrades table for upgrades from a configured list (each XF user upgrade has an ID) where the users are not already in our 18+ or 18- groups. So essentially we get a list to work through of users who have "ordered" the age verification.
We grab some previous state from the database (additional table is added to the XF db) and then iterate over our list:
If it's an order we've seen before (ie we have state) then we ask for an update on the progress from VeryifyMy. If the state has changed we notify the user. If it's been sufficiently long since we last told the user anything we notify them. Depending on the state we may now add the user to a group. The notifications are all configurable to suit the states. So if VeryifyMy want more information the notification tells the user to go off to the supplied URL to supply that info.
If it's a new order we send off some data to the VeryifyMy service and store the resulting state, acting on it as we did for the orders we'd already seen.
Since VerifyMy is geared up for product sales of age restricted items it assumes you have a name and address to send them to check. So our user upgrades need to use a Paypal (sorry only one I've written a parser for) payment profile that requires a delivery address. That address ends up in the XF payment logs and gets parsed out and sent off along with the paypal owner's name and the XF registered email. I assume they are checking against things like the electoral role. If that first "stealth" as they call it check fails then we end up with the fairly standard trio of: age estimation via video, uploading ID, credit card check.
It's by no means perfect. At present I'm waiting on getting an email issue resolved. So if the "stealth" check fails VeryifyMy send out an email saying "sorry we need some more info before your cool stuff can be shipped". I think those emails can be disabled (since I can use XF notifications), but the flag in the API call doesn't seem to be doing what I think it should. There are of course ways of bypassing the system, but maybe it's best not to shout about them too loudly. I think it probably meets Ofcoms requirements from what I can make out of Ofcom's requirements! The whole thing is a can of worms at best anyway.
The VerifyMy system does support triggering a webhook when the status changed, but for my use-case that seemed overkill since time is not of the essence and I'm polling potentially every thirty minutes, which works.
Paying them is a PAYG process so at least there isn't a monthly cost. Each verification costs 80p so since I am "charging" via paypal I'd need to charge somewhere about £1.20-1.30ish to cover costs. Their contract does lock you into using them as a sole supplier, but at the time they were the only one I could find that was not a monthly contract in the order of £200, so it was a case of "they'll do". I didn't contact all the players however. They supply services for ebay and a few other decent sized players. I can't really comment on them as a company as I've barely spoken with them. The only data they retain for any significant length of time is a hash of the user's email - so basically if they have already seen that email before then you sail through their "checks".
So my current model is to let someone register and then restrict functionality until they have been through age verification. What functionality is limited would be up to you. It could be everything or it might just be say private messaging. Since it's just based on XF groups it's easy enough to tweak.
I may still investigate the Stripe solution (although I'd presumably have to cease my current contract or do Stripe under a different entity), but it's a little more involved since it looked like it did require a webhook. If you're writing a solution as an add-on that's easy enough. We already run a decent sized webhook endpoint for processing other data so I'd probably just write a module for that (which would be very proprietary to my company's architecture) for my own use. The interfacing looks somewhat cleaner I think in the Stripe solution, but I other than a skim of the docs I've not looked at it yet.
I'm sure one of the add-on devs here will be writing something - anyone want to confess?
Granted writing something for the bigger players Yoti / Onfido / etc would take a bit more thinking about (since very few of us are going to want a monthly bill of a few hundred - so the dev might need to sit in the middle), but the PAYG providers should be simple enough to do especially if add-ons are your day-to-day work and I guess is the sort of thing you could charge the typical $10-40 /y type fee for.
www.ofcom.org.uk
There were always issues with that town in North Linconshire too
