Input type tel causing issue in iPhone - iphone

I am using ** PayPal Powered by Braintree for WooCommerce** woocommerce plugin extension for Card Payment.
But i recently found that fields under card payment have input type as tel and this is not allowing me to add symbol slash (/) in Expiration Date field specially in iPhone.
Is there any chance to overcome this issue in iPhone?
Screenshot: http://prntscr.com/ez12xq

Full disclosure: I work at Braintree. If you have any further questions, feel free to contact support.
There are two ways to work around this issue:
Update your placeholder to MMYY (you could do this dynamically based on browser)
Break your expirationDate into two separate expirationMonth and expirationYear fields.
If you're interested in the thought process behind this decision, check out the github conversation

Related

Sendgrid - Error while updating card details and impossible to contact any Sendgrid support

When updating card details, I get the following error:
[ThreeDs2_Authentication_Exception] Transaction declined.402 - [card_error/card_declined/generic_decline] Your card was declined.
The card details are double checked and seem to be correct.
I tried opening a ticket on sendgrid or contact support via chat but apparently that functionality is broken on the official sendgrid site, so I'm trying my luck here.
Any help is highly appreciated.
Try a different browser (like Chrome).
This may or not be a solution, but it worked for me.
I'm on a Mac and couldn't add a SendGrid payment in Brave, but it worked when I switched to Chrome.
Likely it's due to some extensions I have installed, but this happens to me a few times a month on other websites.

Does SendGrid support double opt-in as a feature?

Does SendGrid support double opt-in to Lists as a feature or is that something we will have to implement for ourselves?
https://sendgrid.api-docs.io/v3.0/contacts-api-recipients/add-recipients
It doesn't appear to me to be anywhere in the docs, but I thought I'd ask in case I missed it.
Not as of the current date; I asked their support staff and received the following answer:
Double opt-in needs to be implemented by you in the form/page you're subscribing your recipients. The confirmation email can be sent through SendGrid.
For Marketing Campaigns we have the SendGrid’s WordPress Subscription Widget that makes it easy for people visiting your WordPress site to subscribe to your marketing emails;
or Building a SendGrid Subscription Widget.
I got this answer from their support. It turns out we have to implement it by ourselves.
The double opt-in functionality is not something SendGrid provides as
we expect our customers to handle any opt-in practices on their side.
We apologize for any inconvenience.
SendGrid will be GDPR compliant by May, 25, 2018. Please note that
SendGrid does not – and does not currently have plans to – use servers
or data centers in the European Union to process email. Thus, SendGrid
cannot restrict data to the EU. However, neither current EU law nor
the GDPR require this. Instead, what is required is that SendGrid must
provide "appropriate safeguards" for data that it hosts and processes
on its US servers (see Art 46 of the GDPR here). SendGrid offers a
Data Processing Addendum (DPA) to provide such adequate safeguards,
which includes provisions for when GDPR goes into effect.
More info on GDPR can be found here. Our DPA can be reviewed and
signed by filling out the information here.
They do not support it. I asked support many times, which is a strange as it would seem a company of that size could spare the dev resources to build a feature that literally all of their customers need.
However, https://sgwidget.com is a third party product that provides double opt in functionality for Sendgrid accounts.
Full Disclosure: I am a developer at SG Widget.
No, indeed still today, they do not. Not in their forms, nor in their API is there simple, flip-switchable support for double opt-in. But, with email automation fairly recently implemented in their marketing services ("free" and "advanced" plans, not "essential") you can send an automated email directly upon sign-up.
My solution is to have 2 lists for new contacts, where one is a "pre-confirmation" list and the other being the "real" list. Here´s a way to use automation:
Create initial signup form, either via their sparse Web forms or via your own, using HTML/JS/PHP and API endpoint:
Create 2 separate lists, one for "pre-confirmation" emails and the other for people who confirm their addresses.
Make the form sign up new contacts to the first list, "pre-confirmation".
Create a marketing automation flow that triggers upon new signups to the "pre-confirmation" list. Make the automation trigger an email that contains a button or a link with the following link structure:
https://yoursite.com?email=user#email.com&passphrase=[phrase-you-set-manually]
where ?email= is your user´s email, substitute this in the email template/design by {{ Sender_Email }}
where &passphrase= is a phrase long enough to not be guessed. Since you only have one single email design here, and you can only enter one single phrase, unless you make a script or a hash, you make it difficult enough for people to think it was generated by a server :).
On your server/application, yoursite.com, use $_POST['email'] and $_POST['passphrase'], or whatever you name them, to validate the email clicks from your list and then enter all validated emails to the correct list using the PUT
/marketing/contacts endpoint.
you may also have to delete the user from the previous list, using DELETE
/marketing/lists/{id}/contacts, but I do think that the PUT /marketing/contacts takes care of placing the contact in only the lists specified in the list_ids field.
once the contact has been entered into the correct list, you can also have a marketing automation set up for that list, which sends him/her a welcome message.
This method takes care of double opt-in for SendGrid without using one single email credit from the Email API (transactional plan). The only catch is that we utilize one initial and one second/final list to achieve it.
Note: the initial sign-up message that here acts as the "confirm your email" message, will be tied to the first list and will require a marketing unsubscribe link in the footer. Make it clear in the bottom of the email that it is a temporary list, to not get any spam complaints. But it will not be an issue, as we wont be sending to anyone in that list except for this initial time. Unless you have a user who enters his/her email twice, after some time of inactivity when they forgot they already signed up. That could happen. But it´s a separate issue.
I think this is possible by switching the flow of a typical email subscriber. When the user clicks your subscribe button, instead of calling the sendgrid members/contact PUT api to add to your list, send an email with a link to a URL of yours that will then trigger the members/contact PUT api call.
Not sure what stack you are using but I was able to build something like this with next.js utilizing their api routes

Request payment part way through course

I'd like students to be able to access the first couple of lessons in Moodle before being presented with a request for payment. I've searched for ages on Google and found nothing, and also searched for all the possible terms I could think of here, and again come up short. Apologies therefore for the lack of contributing research/evidence.
I'm using Paypal as the chosen method of payment at the moment. Moodle is version 3.2.
Is there a way to add this kind of option to the 'access restrictions' in the courses themselves?
There isn't an existing way to restrict activity access based on the users enrolment type.
Without writing some custom code, the easiest way to do this is probably to have a separate course containing the pay-walled content, with paypal enrolment set up.
Add an activity to the free course with a link to the paid course. Use access restrictions to hide it until the other activities are complete.
When a user completes the free course content, the link to the paid course will be revealed, and they can click to enrol using paypal.

Roadblocks with using PayPal Recurring Payment Subscription with ASP.Net Membership?

I'm using ASP.Net Membership Provider for logging into the premium content of this web site. The content isn't downloads, it's web pages of information and discounts, etc. That part is done. We want them to also have a PayPal Subscription annual payment to see the premium content. I would like ASP Membership and PayPal Subscription to work together as much as possible, but for the minimum I am thinking they will have to create a MemberId before they pay. Then I will send that MemberId to PayPal to associate the two.
I think I can do that like this:
Set "Auto Return" on in the interface so that it will redirect to return URL when payment is made.
Set "return URL" query string to MemberId. This requires not using the precompiled "Saved" buttons. I'll have to set it in Code Behind with Name Value Pairs, "NVP" to PayPal. I was hoping to just paste the stupid button.
But then, there were those "Advanced Variables" in the Button maker. Problem was they are compiled into the Saved button, so I can't change them for each person. But maybe that one parameter could be separate from the compiled parameters? Is this better than hacking the return URL? Are "Advanced Variables" good for anything?
All the details about the transaction will be POSTed to the return URL if I put in the right code, which might be rm=2. (Right?) Then I can record it.
This process is said to be unreliable, though, and PayPal recommends using a secondary system that they have, "IPN". PayPal sends the transaction details to me. I send them back http 200 code. Then I send it back to them in the same order I got it. Then they send me http 200. Then we all know it's good. This sounds like a few hours research to me, but if you've already done it once, it sounds like copy and paste. I hate reinventing the wheel. Is there a .Net sample of this IPN handshake/dance?
Also, if I do the IPN thing, maybe I don't need Auto Return. Maybe I add MemberId to "notify" URL instead of "return" URL. Then PayPal can handle the confirmation page, email, etc. Is that better?
Assuming we get the Subscription paid for and recorded with the MemberId, at least once per user session, after they log in, I have to check if they have paid their PayPal subscription and if it's up to date. "GetRecurringPaymentsProfileDetails" does this, but it is an API operation. That makes sense, but I was hoping to avoid learning their REST API. (Is there a "NVP" version?)
REST API OAUTH tokens expire every few minutes, but the only way it tells to get one is by using "Bash" to "cURL" some Linux commands. Again, this seems like the kind of thing that would only ever have to be written once. Does this already exist as a sample code somewhere?
(I don't want to use the API to do the Subscribe, because I don't want the Credit Card numbers to ever go to our site. Too much liability. That's why I wanted PayPal.)
Will this even work? I know PayPal has 18 ways to do everything and they all exclude each other, and I'm just getting the feeling that I'm creating a patchwork of unrelated ideas to fool myself into believing there's a light at the end of the tunnel. I've already been researching and experimenting for 10 hours or so. I really thought, going in, I'd just be pasting a stupid button.
If you want to just "copy the stupid button" then you'll have to stick to Payments Standard, and then you'll be limited with what you can do. For example, you won't be able to use GetRecurringPaymentsProfileDetails for a standard subscription.
Instead, you'll need to use Express Checkout and / or Payments Pro. There is indeed an NVP API available for these, and there is also a SOAP/XML version. Details on those can be found here: https://developer.paypal.com/docs/classic/api/
Specifically, for Express Checkout, you'll want SetExpressCheckout, GetExpressCheckoutDetails, DoExpressCheckoutPayment, and CreateRecurringPaymentsProfile. Some of those calls are optional depending on how exactly you're configuring things with the checkout flow.
For Payments Pro you'll use either DoDirectPayment / CreateRecurringPaymentsProfile or PayFlow depending on what version they put you on.
In any case, IPN is definitely the way to go for post-transaction processing.
.NET IPN Sample - https://github.com/paypal/ipn-code-samples/blob/master/paypal_ipn.asp

Problems adding credit card for app verification

I'm trying to create a test app, which requires giving Facebook a credit card for verification (or a cellphone, which I don't have). Unfortunately, when I enter my credit card information (and it's all correct and valid), I get the error:
Sorry, we were unable to process your order at this time.
How can I add a credit card and verify an app?
There seem to be two different methods for adding a credit card - The obvious one is directly through the standard Accounts page.
https://secure.facebook.com/settings?tab=payments&section=methods
The second, is through another page, but I haven't found where the page comes from. This (hard-to-find) second page worked fine for me. I added my credit card, and was able to create a test app with no further problems.
https://secure.facebook.com/cards.php
Update - I finally received a response from the Facebook support team, and they suggested that I use the second link, to fix the problem. While I'm sure the comments are correct, that this is an orphan link - it's still a bit funny.