Been googling all day, reading numerous PDF's and still getting confused with the concepts of sending data to Payway system from Westpac (a bank in Australia). They offer access via API but also give access via what they call "NET."
The way I understand is that when client want to pay on my website, in case of NET, client gets to the page (hosted by a bank or hosted by me) where is provided with form to enter credit card info details. Then this form is submitted via normal POST call to Payway's specific https address. It is processed then and browser returns to the URL I specified as one of the parameters I sent in hidden field.
In case of API story is similar, so user receives form, fills in the data and then data is send to my backend (not Payway's). My backend then calls payway API with data provided and once answer received returns confirmation page to the client.
Is my understanding right? Please explain as I have a feeling I am missing something basic here.
There are a number of different ways to interact with PayWay Net, depending on how much control you want. The simpliest way is this:
You create a HTML format containing fields with certain names. This form is served up by your website, but when submitted goes to the PayWay website. You can add to this your own hidden fields and information fields.
Your user enters some details and clicks Submit.
Your user's browser submits the form to PayWay. PayWay validates the values and displays a page asking for credit card information (over https)
The user enters the credit card details then confirms the transaction.
PayWay processes the credit card transaction
Optionally, PayWay can conduct a post back to your server indicating the status of the transaction so you can complete the order (called server-to-server payment notification)
Optionally, PayWay can redirect the browser back to your server (but do not use this to update yoru database)
There are also ways to fully customise the credit card input page and receipt page.
PayWay API is different. You install a piece of software on your server. When you want to conduct a credit card transaction, you invoke this piece of software. It talks over the internet to the PayWay server, conducts a transaction, and gives you a response. You could use this if you were writing a phone payments system, for example, as no browser is involved in the PayWay interface.
(Disclaimer: I work for Qvalent, developers of PayWay).
Your understanding is correct.
I've done a couple of Payway integrations and have always opted for the API solution so that users get a consistent experience and are not jumping between websites.
An odd thing about PayWay, is that while most payment gateways have 2 options.. a merchant hosted or server hosted, PayWay offers this pseudo-merchant hosted with their NET option using the token request. Credit Card details are taken directly on the merchant site and only redirects the confirmation momentarily to the server and then back. This would be great if a payway account worked universally with both NET and API.. but it seems an API account doesn't support NET methods. So if you want to accept cards on your site, the NET token method is pretty much eclipsed by its bigger API brother.
Related
We faced with testing problem on the side Google Pay.
At the current stage, we get into the GPay only after Card registration on the side of our site, when after filling out the form user is redirected to the GPay page to create a new Card.
A Card is being created : we see it with the data that is entered into the form, but the GPay doesn't send any requests to our site. A special test environment from GPay is needed?
Google Pay's support service asks: "Are you receiving the POST from GPay when you attempt the enrollment flow from the app?"
How we can apply from GPay if we can't create a Card from GP at this stage?
The process of creating a Card is described in paragraph 1 (on the site side).
How to get into the GPay for enrollment at the testing stage?
Support service writes "When you submit your user details from GPay, it sends a POST request to your server so that when your page is displayed it contains the information from the user data form. "
As we pointed, at the current stage we can't send data from the GPay.
It was expected thatGoogle Pay's support service send a POST request to our site, but we don't see POST request's body. It is empty.
Therefore, we asked earlier, What internet service we can see it with?
They answered, as we understood, that we can see it by sending from GPay.
How to send it from the GPay, if at the testing stage we can only see
newly created cards and we don’t get any requests from GPay?
Is testing take place from GPay app?
If so, why don't we have an access?
We get a request POST, but with an empty request body.
The GPay has a lot of users with the Loyalty Card.
Someone has already come across this.
We didn't find such situations on the Internet.
How anybody have handled situations like this before?
How to create a new Card from GPay and see a POST request?
We do not have access to the class settings in the account. On Russian language, we do not see the callback feature, and on English technical support sends to us a screenshot - there are settings in the account. Could there be access rights issues?
To accoding with your link from paragraph 5 https://developers.google.com/pay/passes/rest/v1/loyaltyclass#discoverableprogrammerchantsignupinfo - we did not find the insert barcode /manually settings. Can you tell us where to find them?
At the moment, we can scan the barcode in GPay app(due to help of GPay support service ), but we do not receive a Post request after inserting bar code in GPay app.
Our Russian account settings looks like:
GPay support service see our account on English so:
We don't see these settings for barcode.
In accordance with the documentation https://developers.google.com/pay/passes/guides/overview/how-to/use-callbacks, we set up a callback feature, but we do not receive a post request in the format json (php):
$responseJson_str = file_get_contents('php://input');
$responseJson = '[' . $responseJson_str . ']';
$response = json_decode($responseJson, true);
var_dump( $response);
$file_server = "server_calback.log";
$fw = fopen($file_server, "a");
fwrite($fw, "POST " . var_export($response, true) . "\n");
fclose($fw);
What is wrong?
I show a screenshot with the request POST to our site
https://itcrk.icu/testcallback.php
from https://reqbin.com/
At the beginning of testing stage, we implemented signin / signup as you indicated in points 1-6. We did this functionality was not because we needed it, but thought that it was necessary for testing.
Then we wrote in support team that we need a barcode/manually, as users of other cards are used to. We were answered that we need settings in the account, we did not find them. Support team helped us to configure the barcode in the account of the Merchant Center - Google.We insert barcode in the GPay , but we don’t get json on the site. We assume a problem with access rights in the Merchant Center - Google. How do other cardholders usually set up a barcode in their accounts? We do not have access to the settings n the Merchant Center - Google, unfortunately. Support team writes that there should be access, but it does not.
It turned out that there are two ways to work with cards in the GPay. The first method is described in the documentation here https://developers.google.com/pay/passes/guides/enrollment-signin, the second method is to scan the card(barcode/manually) and use it as a card storage, but card data is not sent to the user’s server.
The Loyalty card is simply displayed in the GPay with its number(from barcode/manually) and that's all.
Sign up and enrollment are triggered from the google pay app: https://developers.google.com/pay/passes/guides/enrollment-signin
You will see post once a user goes into the Google Pay app and hits add pass then finds your program and hits sign up/ sign in.
See 1-2.
You have to use the account you provide to support team - its only visible for them for testing.
It may not be from Google. Google requests have the body with the user details.
Go to google pay app and sign in with user that is whitelisted by support to see the program. Hit add pass, then loyalty program then search for your program then hit sign up/ sign in and it will post to the endpoint defined here: https://developers.google.com/pay/passes/rest/v1/loyaltyclass#discoverableprogrammerchantsignupinfo
Let me also clarify enrollment and sign in. This is what a user sees, what the Google Pay app does and finally what a merchant needs to do:
Google Pay user navigates to passes tab in Google Pay App, hits "+ Pass":
Google Pay chooses which type of pass to add, hits loyalty for this example:
User searches and presses on the specific program they want to sign up for (theres a testing phase before it goes public, in which only accounts which you tell support team can see the program in google pay app):
User then fills out information to share and consents to share their information with this merchant, then they press continue.
Google Pay Then does a POST request with user info to endpoint defined here on the loyalty class by merchant: https://developers.google.com/pay/passes/rest/v1/loyaltyclass#discoverableprogrammerchantsignupinfo
Here is where merchant, yourself would have to be listening for POST to endpoint you defined in the setting mentioned previously and give user form to finish providing all details needed and then redirect to the JWT link to automatically save the pass.
See https://developers.google.com/pay/passes/partners/enrollment-signin for reference.
It turned out that there are two ways to work with cards in the GPay. The first method is described in the documentation here https://developers.google.com/pay/passes/guides/enrollment-signin, the second method is to scan the card(barcode/manually) and use it as a card storage, but card data is not sent to the user’s server. The Loyalty card is simply displayed in the GPay with its number(from barcode/manually) and that's all.
A client I work with wants to know if it's possible to use the Yodlee API to look up recent transactions on any credit card.
They'd like it to work without the user needing to be signed up with Yodlee, either directly at the site, or indirectly through a branded partner.
I assume this would be possible if the credit card company itself shared it's transaction data with Yodlee directly, and made it available to their API customers, but I haven't been able to figure this out from the docs available on their website, and haven't been able to reach anyone at Yodlee themselves to ask.
I work for Yodlee. Sorry to hear you're having a hard time getting a hold of us. To answer your question, yes the user has to explicitly authorize any application that leverages the Yodlee API and explicitly add access to their financial accounts for that application.
Best,
Grace
Yodlee screenscrapes websites to retrieve it's information.
Which means that they physically (but in an automated fashion) visit the website in a browser (IE8). Thus to pull any information down they have to visit the website, log in successfully, (optionally but more so on more banks; authenticate the computer) and then they can see all of the information that the user sees. Their API acts as a real time bridge between you (the end user using your website or app) and this browser.
So you have to either implement their very much so convoluted Yodlee API or use one of their generic hosted pages and direct the user to it where upon he/she enters the necessary information. You also have to have an agreement with them too. You also have to convince the user to do it :)
how do I get paypal to pass a few variables. I don't want the user to have to login to my website. Just pay. So, they fill in some data related to my service. my site does a calculation, and for the answer, they have to pay. What's happening now, is they pay, but, they have to fill in all the boxes again. I want them to pay, and go back to the page that they filled everything in on.
I would need more information to be able to provide you with a specific answer, such as what PayPal service are you using? Are you using Payflow Link, Payflow Pro, Website Payments Standard, Express Checkout, or Website Payments Pro? Depending on what service you are usnig, there are different ways you can pass information over to PayPal, just as there are different ways that you can get information back from PayPal.
If you are trying to get information back from PayPal and are using Website Payments Standard, Website Payments Pro, or Express Checkout you can use IPN to get data back to your site. You could also use API's suce as the GetTransactionDetails API to get information back. If you are using Payflow Link, you could use SilentPost to get databack to your site.
If you are just trying to to send data over to PayPal, there are different variables that you can populate and send over to PayPal. Depending on which service you are using, these variables may be different. I would suggest looking at the developer's guide to see what variables you can use.
I am so confused about the services and over here the paypal website also seems to be serving up 400's and 404s.
This is how the webpage looks for customers on my site when they are ready to pay:
As far as I know, I don't have Express Checkout, but I'm not sure if I have Website Payments Pro (my company created this account).
Now I have two questions:
1- This is just the sandbox. But on the real site, does this solution that give users the opportunity to pay by credit card? I've actually successfully done a credit card transaction in the sandbox, I'm just worried because I've heard that customers can only do direct credit card transactions in PayPal Website Payments Pro. The PayPal website is overloaded with information and I can't find my way around it to answer simple questions like this.
2- Is it possible to do negative testing for transactions on this page? Such as simulating the events that the user's credit card or Paypal account doesn't have enough balance? If it is possible, and I am using the ButtonManagerAPI, then is the technique below the correct way to go about it?
I put an error code in the amount variable that is passed on to IPN via via an NVP api call, like this (lots of value pairs in the middle excluded as irrelevant):
$nvpReq = "BUTTONCODE=HOSTED&..............&L_BUTTONVAR1=amount=".$err_code
EDIT
So it appears I have PayPal Website Payments Standard, which means I cannot incorporate cannot have credit card payment forms directly on my website, but customers have to be directed to PayPal. I'm fine with that, as long as customers have the option to pay with credit cards.
The screenshot looks like PayPal Standard, which is an HTML-only (non-API) integration.
Any regular business account that can receive money can make use of the Express Checkout API.. typically by authenticating with an API USER/PWD/SIGNATURE. For businesses with programming/development resources, EC is by far the recommended way to accept PayPal payments.
If you pass SOLUTIONTYPE=Sole in the initial SetExpressCheckout call, it will accept credit cards from "guest" customers who don't have a PayPal account, similar to the Standard screenshot you're displaying above.
The main reason to choose EC over Standard is that it's a much tighter handshake between your checkout software and PayPal's servers. With Standard's HTML-only, the customer is redirected away from your site and might not return to your site after a successful transaction is committed (they may stay on paypal.com and not click to return or their browser might crash before return --- whereas with EC the return to your site is built-in before anything touches the financial system)
With the recent beta of developer.paypal.com, all new sandbox Business accounts are full Pro accounts by default. Signing up for a live Pro account would be useful if, in addition to accepting PayPal payments, you wished to create a credit card entry form directly on your own site.
Here are some EC links for programmers:
https://tryit.paypal.com/guide/ec
https://paypal-labs.com/integrationwizard/ecpaypal/main.php
The button manager API is unlikely to be useful to you. And there are ways to do negative testing with the sandbox, but it's really not an important concern when you're still deciding on a product/API.
I have a single authorize.net account, and I have 5 different e-commerce applications tied to that account. Some are posting from a public site and some are posting from managed access sites. I am using SIM and I have read about the Relay Response, but as far as I can tell I can only have one URL listed. That will not work for me as I need a different URL for each different point of entry into the e-commerce system.
My problem at the moment is that I need to update a datafield via a guid upon successful payment completion to confirm purchase of a digital item, but if I put in a relay response page it is getting sent to all my access points and throwing errors. Other parts of the e-commerce system need to send different emails upon completion etc, plus all the urls are different at the top level.
Is there some other way of accomplishing this task that I am overlooking?
Use Silent Post*. It's Authorize.Net's equivalent of Paypal's IPN. It will only post to one URL per account but it happens behind the scenes. This means you can send a custom flag along with each transaction identifying which site the purchase is for and then have it respond accordingly (e.g. send emails, update database, etc).
*I am the author of this content