Webhook question

The SKUs are unique and needed for Stripe on our end. We can either send those and include the SKU in your add-on management table so you can see them, or we could use the URL title since that will be unique. I mean, we can send anything that you need and I suppose now is the time to request it before anyone’s using the web hooks. 😊

Good call on the test button, I’ll get that added this week.

TBH as much as you can send that is GDPR friendly would help :D

At the very least knowing which add-on(s) were purchased (by Title, URL Title, or something else) would help a lot.

I’ve added a test web hook button on your management page. Let me know if it’s missing anything that you’d like.

Very cool, wasn’t expecting it that quick. I was planning to work on this stuff tonight regardless, but having the test button will be helpful. Thanks!

I was able to get this working last night. For anyone else looking to implement the hook, here is how I did it.

public function ee_store_web_hook()
    {
        parse_str(file_get_contents('php://input'), $data);

        $code = $data['license_number'];
        $date = $data['created'];
        $urlTitle = $data['url_title'];
        $entryId = isset($this->addons[$urlTitle]) ? $this->addons[$urlTitle] : false;

        if (!$entryId) {
            return;
        }

        ee()->db->insert('store_licenses_unclaimed', [
            'entry_id' => $entryId,
            'code' => $code,
            'date' => $date,
        ]);
    }

While working on this, I realized it could be a slight security issue that there is nothing authenticating the webhook. What do you think about adding a new field in the settings section where you define the url to the webhook that either randomly creates a passphrase/token or lets us define the token value, then that value is passed along with the rest of the data in the webhook, and we can then validate the request?

Another scenario that came up while I was implementing the “claim a license” on boldminded.com… What will happen when they renew? Will it issue a new license number? If not, would the webhook be able to send another parameter such as “renewed” or “renewed_date”? That way once a user has claimed a license and added it to their account I can just update it.

Thanks again for the webhook. My biggest concern with the store was how I was going to handle support, and know if someone requesting support has a valid license or not. This lets me achieve that.

Seems that being able to update if you want would be helpful, so even if a new license were generated, sending the old one with a renewal event would be good. We should probably be sending an event name as well to make it easier to handle different types of events on your end.

Yeah, either option is fine with me (update boolean, or new license # along with the old license #).

So if we can’t get their personal info due to GDPR, which means we can’t contact them directly until they come to our site (if they come to our site), would it be possible for each add-on dev to have a textarea field in their account where they can add a short message to the end of the purchase email they get from EL? That would allow us to provide followup info. In my case I could mention the boldminded.com/claim url and the process of linking their purchase to my support system. I wouldn’t expect rich formatting, just a basic textarea field would be enough.

Can we also get the stripe transaction id and customer name and email?

When you say the Stripe transaction ID, do you mean the ID for the vendor payout so you could build links to it, etc.? Or something else?

Name and email I certainly understand wanting, but I’ve not found a way to handle that that is compliant with GDPR. Suggestions?

1) Stripe transaction ID — yes, the ID for the payout — we get an email from stripe, but we have no way of knowing what add-on it’s for, especially tough if two of our add-ons are the same price, or if someone buys more than one add-on at once.

2) What is the GDPR compliance issue? Certainly, my experience with other middle-man sites is that buyers and sellers can still know each others’ identifying information.

∞ Travis

1) Sure that sounds good. Can you forward me one of your emails so I can see what Stripe sends you by default?

2) GDPR doesn’t allow sharing of any Personally Identifiable Information (PII) without opt-in consent from the user. I can’t think of a clear way to do that that isn’t annoying to the customer. Plus it means that they don’t have to, so by default they wouldn’t permit that sharing anyway. And by sharing PII with a third-party, that makes the third-party a “data processor” for us, and puts EllisLab on the hook for whatever you do with that data, including chasing down and sending right to be forgotten orders around if a user ever issues a right to be forgotten with us. I’m not sure what app stores you’re referring to but Apple, Google, and Amazon do not share the customer’s PII with the third-party seller, even in markets that only sell to US-based customers.

Derek, have you guys talked about this at all?

So if we can’t get their personal info due to GDPR, which means we can’t contact them directly until they come to our site (if they come to our site), would it be possible for each add-on dev to have a textarea field in their account where they can add a short message to the end of the purchase email they get from EL? That would allow us to provide followup info. In my case I could mention the boldminded.com/claim url and the process of linking their purchase to my support system. I wouldn’t expect rich formatting, just a basic textarea field would be enough.

I see some sales coming in, which is good, but I feel totally disconnected from customers right now. I can’t even see the sales info when I manage my account on ee.com. I don’t know if they are new customers, or if they are existing customers buying from a different location.

Hi, EllisLab.

Online middlemen stores do give necessary information about customers to vendors… Etsy, Ebay, Amazon, etc. do. AirBnB gives renters and hosts a way to communicate. Patreon, Kickstarter, Feedburner, Salsa, and Devotee all give email addresses to the providers, in order that they can properly serve the customer.

I think it’s entirely reasonable (and I believe it is legal under GDPR) to give developers some means, even if opt-in, of identifying our customers, so that we can identify paying customers to provide them with support.

“GDPR doesn’t allow sharing of any Personally Identifiable Information (PII) without opt-in consent from the user. I can’t think of a clear way to do that that isn’t annoying to the customer.”

Sounds like a job for James — I have high confidence in his ability to design a good flow that encourages buyers to opt-in and share their contact information with the creator of the add-on they are trusting and relying on.