When testing a whmcs payment gateway, it's capture function
function mygateway_capture($params)
{
}
is never called. I have settings
Auto Redirect on Checkout:Automatically forward the user to the payment gateway.
What is happening now is, just after selecting the gateway and checkout it's redirecting to site.com/cart.php?a=complete (Order Confirmation page)
without any transaction. Any idea why it's so?
Related
I'm trying to setup oAuth for Stripe's Connect (Standard). In their setup documentation they say:
Step 1: Create the OAuth link To get started with your integration,
Your client_id, a unique identifier for your platform, generated by Stripe
Your redirect_uri, a page on your website to which the user is
redirected after connecting their account (or failing to, should that
be the case), set by you
Step 3: User is redirected back to your site After the user connects
their existing or newly created account to your platform, they are
redirected back to your site, to the URL established as your
platform’s redirect_uri. For successful connections, we’ll pass along
in the URL: The scope granted The state value, if provided An
authorization code. The authorization code is short-lived, and can be
used only once, in the POST request described in the next step.
The way I've implemented this is by sending the user to a React-Native WebView, and because this is a mobile application, a redirect_uri is not an option.
The problem is, I cant simply make a POST request to a url. there are user actions that must be taken inside of stripe, and ultimately stripe sends an authorization code to a redirect url.
So How can I obtain the authorization code that stripe doles out inside the WebView authorization process so I can finish the Stripe Connect user creation process?
You can use onLoadStart for WebView. Just check if the url from the synthetic event is what you specified in your stripe settings and handle accordingly.
onLoadStart={(syntheticEvent) => {
const { nativeEvent } = syntheticEvent;
if(nativeEvent.url.startsWith("YOUR_REDIRECT_URL"){
// your logic here
}
}}
Follow the steps
step 1 : login in mediator strip account, now open new tab and paste below url in new window and replace client id "ca_****" with the account which you want to connect with mediator account ( client id ), and hit the url
https://connect.stripe.com/oauth/v2/authorize?response_type=code&client_id=ca_************************&scope=read_write
step 2 : now press connect button and find the code from new url like
https://connect.stripe.com/connect/default/oauth/test?scope=read_write&code=**ac_**************************
The only things I need:
Get order id and customer id.
Create redirect url (this must be done on backend, url is signed with private hash)
Redirect user to this user
Upon success verify signature of redirect data and set order status
Upon failure verify signature of redirect data and set order status
Is there some simple module, which does these things so I can modify it for my needs?
This module should not use deprecated AbstractMethod, if possible.
I'm new to magento and documentation about payment gateway is too bloated. Plus it is hard to understant all these config pools and commands in configuration.
P.S. Magento 2 only with new payment gateway api.
Currently when a user logs out the log out process works correctly but the user stays on the same screen and therefore can still see secure data.
What is the best practice for forcing a browser redirect after logging out of ServiceStack?
It's not possible for the server to enforce a client redirect. It's really up to the client to enforce the security for the data after you logout. If the client has been trusted with the secure data already, during the course of the session, then you need to trust that the client will secure it appropriately when the session ends.
While you can have ServiceStack send redirect headers to the client when logging out, there is nothing requiring the client to actually take that action.
If a JavaScript client makes an AJAX request to ServiceStack to logout, the redirect response doesn't affect the page displaying the secure data, because the AJAX request operates effectively in a separate scope from the page showing the data, and so that page remains unaffected by the redirect. So the redirect is useless, unless the client explicitly provides a mechanism to handle such event.
The client must take responsibility to navigate away from the secure data itself. The best practise would be:
In the success method of your call to the logout action, you should:
Dispose of any sensitive in memory data. i.e. JavaScript Variables / DOM Elements displaying the data.
Delete the session cookie
Redirect to login
If you have secured your service properly, then navigating back through the history should still trigger a session check, for which there will no longer be a valid session, and you should be redirected away.
You previously mentioned using AngularJS. If you were doing this with the $http service, then the success callback can be used, like this:
$http({method: 'POST', url: '/auth/logout', data: { provider: "logout" }}).success(
function(data, status, headers, config) {
$scope.someValue = null; // Remove sensitive values from the scope (though it should be cleared up anyway with the redirect to a different state)
$cookieStore.remove('ss-id'); // Remove the cookie
$state.transitionTo('login'); // Redirect to login state
}
);
This example assumes you have injected the $http, $cookieStore, $state providers
tl;dr
The client must enforce the security. The server redirect should be treated as nothing more than a suggestion to the client.
Use the success callback of the logout request action to delete the session cookie, dispose of any values in memory and redirect away from the data.
Hope this helps.
I'm using FOS UserBundle and I have defined a custom AuthenticationSuccessHandler to show a different home page depending on the roles, but I think it should be called only if the user originally requested the login page, shouldn't it ?
On login success I'd like to be redirected to the original request.
As described in the docs, it seems to be the default behavior, but in my case, it still uses my authentication handler.
Can someone help me to redirect the user to his original request ?
For the record, here is how I registered my authentication success handler service:
services:
security.success_handler:
class: Glide\SecurityBundle\[...]\AuthenticationSuccessHandler
public: false
arguments: ['#router', '#security.context']
Yes, the default behavior is to redirect the user to the page they originally requested. However, since you are overriding the default authentication handler, you need to handle redirecting them to that page yourself.
I recommend you look at symfonys authentication handler and mimic its process for figuring out the users original request.
I am currently implementing Paypal's express checkout using JAVA, interfacing with the PayPal NVP API. I have SetExpressCheckout, GetExpressCheckoutDetails, DoExpressCheckout, DoAuthorization and DoCapture methods all working. However, I need to implement the Instant Update API in order to calculate shipping costs and taxes on our server and display in paypal's page. I followed all the steps and recommendations, however, the callback is never called. I have tried playing with the setExpressCheckout parameters as I read in this forum that those parameters could be the problem but couldn't make it work yet. When I log in or change shipping addresses the callback is never called, I'm in sandbox environment BTW.
My callback url is public and works properly. When trying with a webbrowser it invokes my payPalCheckoutUpdate method and writes in a log file in my server, so I'm positive that the url was called. The problem is that when I log in paypal's checkout mobile site or change shipping address this callback url is never called.
My paypal update method is hosted in an Apache Ofbiz based application, I found in different forums that paypal can't access ofbiz's urls in port 8443 or 8080. So I used apache to redirect from my callback URL to my actual method and avoid using a port different than 80 in the callback url. (this works fine when tested with a webbrowser)
This is my call to setExpressCheckout without the credentials (let me know if you see a problem in this call)
372623 [http-0.0.0.0-8443-3] INFO com.paypal.sdk.core.nvp.NVPAPICaller -
L_SHIPPINGOPTIONAMOUNT0=0.00&CANCELURL=https%3A%2F%2Fdev2.XXXjacker.com%3A8443%2FXXXjacker%2Fcontrol%2FpayPalCheckoutCancel&MAXAMT=80.99&L_SHIPPINGOPTIONLABEL0=Calculated+Offline&AMT=80.99&RETURNURL=https%3A%2F%2Fdev2.XXXjacker.com%3A8443%2FXXXjacker%2Fcontrol%2FpayPalCheckoutReturn&CALLBACK=http%3A%2F%2Fdev2.XXXjacker.com%2FpayPalCheckoutUpdate&L_SHIPPINGOPTIONISDEFAULT0=true&L_AMT0=80.99&TAXAMT=0.00&L_QTY0=1&L_NUMBER0=286202&SHIPPINGAMT=0.00&L_NAME0=DVD+%2B+VCR+w%2F+Line+in+%28no+tuner%29&ITEMAMT=80.99&CALLBACKVERSION+=84.0&VERSION=84.0&L_SHIPPINGOPTIONNAME0=Calculated+Offline&CALLBACKTIMEOUT=3&METHOD=SetExpressCheckout&CURRENCYCODE=USD&PWD=**&SOURCE=PAYPAL_JAVA_SDK_76.0&SIGNATURE=****&USER=xxxxx_12xxxx643_biz_api1.xxxxxxxxxxxxx.com
I tried with and without L_SHIPPINGOPTIONLABEL0 parameter, and also tried with version and callbackversion set to 76.0 (the default set by the java library I'm using, taken from paypal) I always get the same result, the callback url isn't invoked.
And this is the response from paypal:
373536 [http-0.0.0.0-8443-3] INFO com.paypal.sdk.core.nvp.NVPAPICaller - TOKEN=EC%2dXXXXXXXX03911650G&TIMESTAMP=2012%2d06%2d12T22%3a03%3a06Z&CORRELATIONID=f1e3c64211d5e&ACK=Success&VERSION=84%2e0&BUILD=2975009 Ack : 200 Elapsed Time : 914 ms
Thank you in advance for your assistance in this matter.
Callback may need to be SSL?:
http://www.konakart.com/forum/index.php?topic=280.0
http://afillyateit.com/forums/topic/500