I am using the Drop in form in the Javascript v3 client SDK to render my credit card form in an Angular JS SPA as follows:
braintree.dropin.create({
authorization: clientToken,
container: '#creditCardForm',
paypal: {
flow: 'vault'
}
}, function (createErr, instance) {
instance.requestPaymentMethod(function (err, payload) {
if (err) {
return;
}
$http
.post('/api/[webAPIPaymentMethod]', JSON.stringify(payload.nonce))
.then(function() {
_showAlert('Payment details were successfully updated.', 'success');
})
}
}
This works like a charm in Chrome and Firefox but for some reason IE11 and Edge just completely bombs and gets infinitely stuck in what appears to be while calling the requestPaymentMethod in the drop-in form SDK.
I see the following (test credit card used from Braintree documentation) with the progress bar just scrolling away infinitely and nothing else happening until I hard refresh the page.
Anyone run into similar issues? I'm not quite sure what's wrong here.
UPDATE: I have reached out to Braintree support. We do have a staging application that demonstrates this issue but I will have to get the appropriate clearence to provide a link to it. Unfortunately there is no activity whatsoever on the dev console. No errors on the console, no calls to an external Braintree API endpoint on the network tab.
It must be something about how we've done it on our Angular app as the .NET sample in here works fine in Edge and IE11.
Related
My backend successfully validates the merchant and a session is returned, but when I complete the validation on the browser, it immediately cancels the transaction. There are a few similar complaints on the Apple Dev forum, but none seem to have been answered; I'm hoping you guys can help!
Out of all the event handlers on the ApplePaymentSession object, only onvalidatemerchant is called, then as soon as completeMerchantValidation with a valid session object (see payload below), oncancel is triggered.
Session config (on browser)
const session = new ApplePaySession(3, {
currencyCode: 'GBP',
countryCode: 'GB',
merchantCapabilities: [ 'supports3DS' ],
supportedNetworks: ['visa', 'masterCard', 'amex', 'discover' ],
total: {
type: 'final',
label: 'My Product',
amount: 9.99,
},
});
Request (on backend)
{
merchantIdentifier: 'merchant.MY.FQDN',
displayName: 'My Company Name',
initiative: 'web',
initiativeContext: 'MY.VERIFIED.FQDN',
}
Response (from Apple to backend, then sent to completeMerchantValidation
{
"epochTimestamp": 1552090296444,
"expiresAt": 1552093896444,
"merchantSessionIdentifier": "LONG_STRING",
"nonce": "XXXX",
"merchantIdentifier": "SAME_AS_IN_MY_MERCHANT_ID_CERT",
"domainName": "MY.VERIFIED.FQDN",
"signature": "XXXXXX-VERY-LONG-STRING-XXXXX"
}
I'm definitely sending this response into completeMerchantValidation as a JSON object and not a string, like so:
console.log('session is a', typeof(result), result); // says: object
session.completeMerchantValidation(result);
The domain name this is all happening from (and hosted on Firebase) is verified against this Merchant ID and I don't get any errors either in the backend or the browser console, no exception is thrown to catch, it just shows the Apple Pay tray, then says "Payment not complete" and hides the tray very quickly. Help!
UPDATE: Looking at the docs, it appears that startSession (which is being returned by onvalidatemerchant is being phased out, so I have tried replacing it with paymentSession (e.g. https://apple-pay-gateway-nc-pod5.apple.com/paymentservices/paymentSession); but I still get the same response and behaviour.
This solution may or may not work for you, but I was experiencing the same issue in that the session was being cancelled as soon as session.completeMerchantValidation() was called.
It boiled down to the merchantSession being created with a domainName value that was not verified (see: https://developer.apple.com/documentation/apple_pay_on_the_web/configuring_your_environment)
I used a local webserver broadcasting through Ngrok to validate a temporary URL by putting the apple-developer-merchantid-domain-association.txt file where it needed to be based on Apple Pay documentation.
After that, as long as I was using a sandbox iCloud account and a test Apple Pay card, passing the ngrok URL as the domainName value for the merchantSession request worked and Apple Pay finally started working locally. Note that I had to interact with my locally running web application through the ngrok url for Apple Pay to work.
I had the same issue where the payment sheet would display then go away without a chance to authorize the transaction. I made sure the domain was verified, the certificate was valid, and that I was actually receiving a response back from the server side request to Apple. Sorting through the process of elimination I came across certain interesting observations:
If the payment sheet disappeared immediately, it was usually due to a configuration issue with the server side request payload (for example, the "initiativeContext" was "something.com" when I was actually using "www.something.com" in the web browser address).
If the payment sheet disappeared after several seconds, it was usually due to a syntax issue or error in the client side JavaScript. In my case, I was not doing session.onpaymentmethodselected and session.completepaymentmethodselection correctly. So I removed all other Apple specific JS functions except for session.onvalidatemerchant and a subsequent call to session.completeMerchantValidation passing the Apple response from the server side request. It then worked.
If the Apple response from the server side request was in any way (even just the casing) changed from what Apple originally sent it would not work (for instance, "epochtimestamp":1668095263534," vs "epochTimestamp":1668095263534,").
Hope that helps.
I'm trying to communicate slack with my application using https://api.slack.com/interactive-messages documentation.
I'm facing one issue while trying to send interactive message from slack to my-app.
Here is my app.
https://gitlab.com/sureshgoud9999/slack-api-test.git
I've placed one "/api/messages" end-point of "POST" method to respond for interactive messages from slack,
here is the flow,
oauth-route.js
oauth-dao.js
Even though, I added bodyParser.urlencoded({ extended: false }) in server.js file, it is not redirecting the request to proper method. Message deliver is failed while clicking on any buttons from slack.
Please help me out if I'm missing anything.
The issue was with URL-encoder. Its solved now.
#ErikKalkoken
Here are the tutorials mentioned,
https://api.slack.com/tutorials/tags/slack-apps
https://api.slack.com/tutorials/intro-to-message-buttons
passing urlencoder to the endpoint was not proper,
var urlencodedParser = bodyParser.urlencoded({ extended: false })
app.post('/slack/slash-commands/send-me-buttons', urlencodedParser, (req, res) =>{ ...}
For some reason the mobile authentication detection stoped working. When I access a location containing a form on my page, the form should call (via ajax) for additional information to fill the fields, the server returns depending on user authentification. It worked well for nine months, but stoped working for mobile devices, however it still works for desktop browser access. Mobile and desktop use exactly the same access route, arguments, urls, view function ... everything. The one difference that I noted (after some 8 hours on this issue) when I looked up the request.META, is that desktop sends cookie information, mobile doesn't. However cookies are enabled on mobile and desktop browser. I tested this with Chrome mobile and (a freshly installed) Firefox on mobile, the result is exactly the same.
How is this possible? Why does the form when initializing on desktop send the cookie info and when initializing on mobile don't send it?
Here is a previous version of this question (written before I noticed the cookie difference and thought it was an api issue) containing technical details that I don't consider to be relevant for the particular question of how does the same functionality behave some differently on mobile and desktop.
EDIT: I really don't know what code to show, but probably the ajax request could be relevant. I am really lost here. This is the react-js service I use to load form initials, it's the one that arrives without cookie information when send form mobile device, and with cookie if send from desktop device, to the server. I am not aware to have added anything or changed this in anyway in the past nine months, it always worked only like this:
loadFormInitials = (typ,genderRelevant,auth) => {
$.ajax({
url: UserConstants.BASE_URL+'elements/?item=setup&auth='+auth,
method: 'GET',
dataType: 'json',
success: (result) => {
var data = JSON.parse(result.initial_data);
FormActions.loadFormInitialsAction(data,typ,genderRelevant);
});
}
Mobile companies sometime alter HTTP requests with their heavy caching.
You'd probably want to try again with HTTPS requests, not sure it'll fix though.
Recently I got to the point to host a static webpage with a subscription option on aws s3 while website development is undergoing. My static web page makes an ajax call to another RESTful service with an email of a subscriber as a parameter. When subscription is done I need to notify a subscriber. Here it seams an issue with the callback.
$.ajax({
type: 'GET',
url: 'http://www.my-domain.com/api/Subscribe?email=' + email
}).success(function (data) {
if (data) {
alert('Thank you for registering!');
}
});
After subscription is done ".success(" doesn't fire up. Response on the request is:
Reload the page to get source for: http://www.my-domain.com/api/Subscribe?email=john.smith#simplyemail.com
Does anyone know if it's an s3 feature or something else?
As per your description this seems to be related with CORS policy.
Look to "why CORS" as Amazon defines it:
In order to keep your content safe, your web browser implements something called the same origin policy.
The default policy ensures that scripts and other active content
loaded from one site or domain cannot interfere or interact with
content from another location without an explicit indication that this
is the desired behavior.
In certain cases, the developer of the original page might have
legitimate reasons to write code that interacts with content or
services at other locations. CORS provides the mechanism to allow the
developer to tell the browser to allow this interaction.
I understood that:
[...] ajax call to another RESTful service[...]
Means call to another server, and this may be blocked by Browser because of CORS.
References:
Mozilla
W3C
How can I catch all the AJAX requests that a page makes with a Webbrowser / EmbeddedWB? BeforeNavigate2 unfortunately isn't fired for AJAX requests.
For example: requests which are made when you type in google search bar.
If the environment is under your control. you can use a custom HTTP proxy (based on Indy for example).
See: Indy's TIdHTTPProxyServer: How to filter requests?
Ajax requests can be detected based on their specific header:
How to differentiate Ajax requests from normal Http requests?
Update: this question on the Microsoft web forum has an accepted answer:
AJAX detection in WebBrowser control
If I were you, I would've injected my own script into every page after it's been loaded. This a script that captures all AJAX requests and informs the application.
Using the following code, you may capture every AJAX request made by jQuery (Haven't tried, but I don't think it works for non-jQuery AJAX requests).
$.ajaxSetup({
beforeSend: function() {
// before sending the request
},
complete: function() {
// after request completion
}
});
It's not even a code, but it can give you a clue for what you want to do.
Surely using this method, you're gonna need to somehow communicate with your application. For instance, I'd use my made up protocol and a new window command so that my Delphi component will be able to capture and parse the event.
As I said there are plenty options here and I'm just giving a clue.