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
Related
I am implementing subscriptions to a premium service on a website using Paypal as the payment service. I have successfully created a Catalog Product and Billing Plan through the API, and I am able to get to the payment page on Paypal, but it's not clear how I'm supposed to persist a user identifier through the purchase process.
I assumed it would be something along the lines of passing a user id somewhere, but there's nothing in the Paypal documentation about this. I need to be able to let the user make a purchase and have the Paypal webhook send the confirmation to an endpoint on my site, and that's where I'd expect to get their user id to toggle the subscription on their account on my end.
Is there something I'm missing? There has to be a way to do this cause I'd imagine it's a pretty common use case. If anyone has information or has done this before, I'd love to hear. Thanks.
The only truly secure way I've found when using javascript SDK, is to securely generate a unique custom_id on your server side associated with the user.
Then when you create the buttons, the 'createSubscription' function takes custom_id as a parameter.
Then use a webhook to receive events from your subscription and the custom_id will be present in the body of all BILLING.SUBSCRIPTION events under resource.custom_id.
I am able to get to the payment page on PayPal,
You are vague about what you are doing here. There are multiple ways (and some ways have multiple versions) of accepting subscriptions via PayPal, so it is important that you provide full details about the method you are using.
The time to associate a created subscription ID with a user ID is when it is approved, in the onApprove function if you are using a Smart Payment Button: https://developer.paypal.com/docs/subscriptions/integrate/#4-create-a-subscription
I'm using Paypal rest api to make payment
the workflow is:
Create payment
Redirect to approval Url
User approved (return back to my site)
Execute payment
But there's one thing that I don't want users re-filling shipping address again because it was filled in my website.
So I change the workflow to:
Create web profile (set no shipping field)
Get web profile ID
Create payment with experienceProfileId given
Redirect to approval Url
User approved (return back to my site)
Execute payment
But I found this will create a lots WebProfile every time user request payment.
I think it is crazy to do:
create and delete it later again and again
attempt listing WebProfiles and check which is the one I want to use every time while creating payment
store experienceProfileId as a constant
What is the best practice for handling WebProfile or does there any solution just hiding shipping address while user approving payments?
Maybe this is not the answer regarding this "WebProfile". As a fact, I dont know what exactly "WebProfile" does or is.
I worked on the same Workflow these days. As you wrote I needed to predefine some address. For me it was obvious, that I have to do the database-stuff on my Website. Then I exactly define the order, shipping_address, etc. and send the users to Paypal.
If you predefine the new ShippingAddress() to your ´new ItemList()´ by
$itemlist->setShippingAddress($shippingaddress) the user cannot change it within the Process.
http://i.imgur.com/nAg8jxU.png
Maybe this helps you a little.
I'm trying to track clicks from our site to an external website. On the external website, I'd like to place some code on their checkout thank-you page, that tells our server that a particular click has resulted in a sale.
How does this tracking code work? Does it need to be a pixel? Do we need to drop a cookie before we send the user to the external website?
Thanks.
Pixel-based conversion tracking is pretty straightforward. You set up a basic web server to accept HTTP GET requests and write logs for those requests. On the merchant's confirmation page you put an image where the src attribute is a URL on your tracking server. That URL contains any data you need to collect for the sale, which will show up in your server logs.
(No, this doesn't need to be a pixel. It can be any excuse to make a client request something from your server. XHR requests, script tags, etc will work just fine.)
Example: if you need to know the Order ID number and value of a sale, you could have the merchant embed a pixel that looks like this: <img
src="http://tracker.example.com/i.gif?orderID=12345&orderVal=99.95">.
Your server logs will now have a record of sales generated on
that site.
Now you need some way to separate sales you generated from the rest of them. There are three ways to go about this:
you do the tracking,
merchant does the tracking
you work with a third party.
An affiliate network can be that third party, the merchant can track traffic sources and use that data to decide when to display your tracking pixel, or you can track it yourself. Which way you go depends on the terms of your partnership.
One popular and easy way to track which sales are yours is to set a cookie on the same domain as the tracker. Since many clients will block 3rd-party cookies, you will track best if your tracking server is also a redirection server.
Example: on your site you make outbound clicks go through your
tracking server. Whereas you used to have an <a> tag that pointed to
http://destination-site.com/landing-page.html you now send traffic
to: http://tracker.example.com/redirect.php?url=http%3A%2F%2Fdestination-site.com%2Flanding-page.html. In this example, redirect.php
should set a cookie and a redirect to the
destination site.
Your server logs will now have that cookie value on image requests from
the merchant's confirmation page, along with any other data you passed
in the cookie (or associated with it on your back end). Now, when you look at your tracking
server logs you know the image requests with cookies are yours and the others are not.
Things start getting complicated when there are more parties involved, deeper reporting needs, accounting and PII policies to comply with, concerns over fraud, etc but that's the gist of it.
I am developing an application where I have a section only for paid users where they purchase for the section using the in-app purhcase system in iOS. I know that I need to keep track of the purchase history myself, and this is where the problem begins. I have a database and I am capable of storing users in my database, with a web service interface. How can I create a system where a URL is pinged only when a user has made the purchase.
As an example, I have the URL:
http://example.com/registerUserPremium/userid=123456
How can I get this to be called only when a purchase is made? The most elegant way seems like Apple pinging the URL with a special user ID upon purchase, but I can't find a way of doing it. It is obviously not a solution to make the user call that URL within the app, as it can be cracked/pirated. What is a good way of providing such a mechanism that is piracy-proof. My service is web-based, so if I can get this part done, the rest relies on my server-side mechanism (the user will just send a special key that is stored in its keychain, to the server) so I'll be able to finish the project. In short, I need a way to call a URL only when a purchase is made. What are some possible solutions?
Thanks,
Can.
I see two solutions:
"Server product model" (doc): the appstore contact your servers every time a user makes a purchase. In this case you have all of the information right away.
"Builtin product model" (same doc) in which the application gets the receipt from the appstore. In this latter case you can contact your server special URL, providing the receipt information, and the server can verify that the receipt has not been tampered with asking the app store to verify (it's a simple post, see here).
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.