I have few questions concerning PayPal and Classic API. I have spent the last few days reading and experimenting with 1. Single PayPal Payment using variables and HTML post form. 2. Idem but for recurring/subscription payments. Even though I almost succeed to do most of what I want to accomplish, I still have few questions and grey zone I'd like to debunk.
Here it is:
Is it possible to use classic API, HTML form, PayPal variables and post a request to PayPal/Sandbox AND ONLY use credit card information, without having to log in PayPal or have a PayPal account? I never succeed and PayPal always block after you hit the PAY button, returning security codes error message or wrong card/account number etc.
If yes, how and where can I find a real code sample or demo for HTML/MVC-C#?
After a make a payment, I receive an invalid response which nothing happens, then, I receive a second IPN response and this one is verified etc. DO I really need to reply to PayPal/Sandbox to tell them everything is OK? If yes, is there info somewhere or code sample/demo I can see? MY point here is because i receive MANY hits on my IPN and I want to make sure I get the right response, make sure i don't DOUBLE subscribe etc..
Is there A GOOD MVC or C# IPN code sample somewhere? One I could read and analyse/take to handle most possible scenarios/errors/response code and what to do with them? not to copy and paste but something reliable I could adapt to my code.
I have succeeded to get a response to my IPN with a PayPal account only and I had to somehow hack security protocol using this instruction --> ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;//SecurityProtocolType.Tls1.2; and I also had to use ngrok to provide a 'valid' return URL. My question here is, Do I Need to remove that instruction when I go PROD?
Thank you so much in advance,
Mart.
Yes, but this is one of the reasons the question got voted down. You need to sign up for Payments Pro to do credit cards (or you could also use the REST API) and then you would use those specific APIs to process credit cards. The thing is, depending on what version of Pro you end up with or if you decide to go with REST, the APIs are different, so it's hard for anybody to tell you what to use at this point.
Yes, you need to POST back to PayPal to verify that the data actually came from them. This way you can trash any data where wannabe hackers are posting garbage to your IPN listener or anything else like that going on.
As long as your IPN script completes with a successful 200 response back from your server then PayPal will only send a single IPN. If you're getting multiples you must have a failure going on, in which case you'll need to troubleshoot that accordingly.
Yes, PayPal provides lots of sample code. This is another reason your question may have been voted down. It seems you have not taken the time to look into this stuff yourself. Go to http://developer.paypal.com and upon reviewing the APIs you'll find they provide SDKs for different languages. Each of those comes with samples, and their GitHub repos also include samples.
With a quick Google search you'll find loads of tutorials and samples as well, of course.
Within the developer site you'll also find the Integration Wizard, which will let you choose C#, choose the payment integration you want, and it will build it all for you so you can see how it works.
Then, when working on those samples or trying actual code, if you have specific problems / questions, you'd come here and post that specific issue with a code sample that you've tried. Then people here will be happy to help.
TLS 1.2 is a standard requirement for pretty much all web services now because of security vulnerabilities in SSLv3. If you have "hack" anything (outside of configuration files, maybe) then you're probably doing something unnecessary. All it would require is to ensure the software stack on your server not only supports TLS 1.2 HTTP requests, but also uses it by default.
Related
I am using C# WAMP client to connect to the Poloniex exchange to get the real time Market data.AS per the documentation provided by the exchange in order to create a real time order book we have to first get the snapshot of the order book through REST api provided by them and extract the sequence number from it and then connect to the WAMP server to get the streaming data and update the order book snapshot.
I have problem in updating the snapshot order book received through rest api since the sequence number which I received through the REST api is nearly 400k record ahead of the sequence number received through WAMP.
Is there any other way which I could get the real time Streaming data from the POloniex exchange or am I missing anything?
I have the same problem. Seems they have some bug. What I have noticed is that there are different sequences sent in normal update messages and in "heartbeat" messages (the ones without payload). The documentation states that a heartbeat message should repeat the last normal message sequence number. But it differs. However it corresponds to a number returned by REST API. So seems that "works" for heartbeat messages and wrong for normal ones. Looks pretty much as a bug.
Here is also some related question.
UPD: Also checked "newTrade" events with trade history returned by the REST API. Trade IDs in WAMP are significantly lower than actual ones in a snapshot. Seems the events published via push API are outdated by several hours and that is the explanation of all this behaviour. So the push API is unusable now.
And finally, seems that current way to go is using their pure WebSocket API which is used by web-interface. It is located at wss://api2.poloniex.com. The only problem is lack of documentation. One way is reverse engineering the traffic of the web-interface. Some poor pieces of information although can be found in code snippets like this or in discussion here.
The original websocket does not seem to be active. The one that is active is indeed: wss://api2.poloniex.com. I am coding my app in swift but maybe you will find this helpful. For orderbook entries I send the following message: "{"command":"subscribe","channel":"(coinPair)"}".
It is very important to use the quotes correctly (as above). The "(coinPair)" is string interpolation so you can include whatever coin pair you want to get the orderbook for. Of course you have to eliminate the (). These are for swift only.
If you want to get a live feed of the prices of all of the tickers you have to send the following message: "{\"command\":\"subscribe\",\"channel\":1002}". Again be careful to use the correct quotes.
Hope this helps.
I am using the rest API documented here https://msdn.microsoft.com/office/office365/APi/mail-rest-operations and https://visualstudiogallery.msdn.microsoft.com/a15b85e6-69a7-4fdf-adda-a38066bb5155 to analyze e-mails in an application. When I "View message details" in Outlook I see the header fields for:
Message-ID: <1421862991001.54993#domain.com>
References: <1421861073749.70076#domain.com>
In-Reply-To: <1421861073749.70076#domain.com>
Is there a way to access these fields through the rest api? The api returns a ConversationId and Id, but those have different values and nothing that can give the context of a message like In-Reply-To does. I realize since these fields aren't documented my answer will be no, but perhaps there is some other way?
I realize this isn't a great example of a programming related question, but I've read this is the best place to interact with the developers at MS responsible for these APIs.
You're right, there isn't a way currently. Accessing the headers (or even the full MIME) would definitely be useful, I will make sure it's passed along.
Chiming in here since it's been a few months since this question was answered.
Accessing the full header information via the REST api would be useful for a variety of reasons, including detecting auto-replies. It'd be great to see this feature happen!
I am working on a project for which I must use Sitecore's E-Commerce Module (and Sitecore 6.5 rev. 120706 - aka 'Update 5') to create a web-store. One of the features that I am trying to implement is a generic promotional/discount code system - customer enters a code at checkout which grants a discount like 'free shipping', '20% off', etc. At the moment, I am looking for some guidance (a high-level solution, a few pseudo-ideas, some references to review, etc) as to how this can be accomplished.
Summary:
What I am looking for is a way to detect whether or not the user entered a promo code at a previous stage in the checkout line, and to determine what that promo code is, if they did.
Progress Thus Far:
I have thoroughly reviewed all of the Sitecore E-Commerce Services (SES) documentation, especially "SES Order Line Extension" documentation (which I believe will have to be modified/extended in order to accomplish this task).
Additionally, I have thoroughly reviewed the Sitecore Community article Extending Sitecore E-Commerce - Pricing and believe that it may be a useful guide for applying a discount statically, but does not say much in the way of applying a discount dynamically.
After reviewing these documents, I have come up with the following possible high-level solution to start from:
I create a template to represent a promotional code, which holds all data relevant to the promotion (percent off, free shipping, code, etc).
I then create another template (based on the Product Search Group template) that holds a link to an item within a global "Promotional Code" items folder.
Next, I use the Product Search Group features of my new template to choose which products to apply the discount to.
In the source code for the checkout I create a class that checks if a code has been entered and, if so, somehow carry it through the rest of the checkout process. This is where I get stuck.
More Details:
No using cookies
No GET requests
No changing/creating/deleting items in the Sitecore Database during the checkout process (e.g., no manipulation of fields of a discount item during checkout to signal that the discount has been applied)
must stay within the scope of C#
Last Notes:
I will update this post with any more information that I find/progress that I make.
I upgrade all answers that are relevant and detailed, thought-provoking, or otherwise useful to me and potentially useful to others, in addition to any high-level answers that serve as a feasible solution to this problem; even if your idea doesn't help me, if I think it will help someone else I will still upgrade it.
Thanks, in advance, for all your help! :)
I sent the link to this question around my office and one of my co-workers who doesn't have a Stack Overflow account suggested this high-level solution, which I am posting on his behalf:
If you cannot use cookies then what I would do is post the entered
code back to the server somehow and store it in session.
You could either use an UpdatePanel control or some JS
Please note that THIS IS NOT MY ANSWER and I am still looking for more potential solutions.
I was working with another co-worker who had some experience using SES in the past and he and I managed to find a DiscountCode field in the Sitecore.Ecommerce.Orders namespace. I have not yet found any methods that actually use this field (and I know for a fact that there are none in that particular namespace), but it does demonstrate that the discount code feature is, at least in some small part, built into the module.
Because it is not in the documentation and there are no results in Google that I have found that refer to this, I am going to leave this question up, rather than delete it. I will be accepting the other answer, as it is a good solution, which we will probably be implementing unless we find more treasure in the DLLs.
I have to implement a payment gateway for a website I am maintaining, and I haven't done anything like this before. Previously to implement payment processing, the site would build a transaction and send it directly to the payment processor and await a result. Since the site handled the gathering of credit card information, building of the transaction, and the requests/responses, there wasn't much I had to worry about that the previous developer hadn't already covered.
Now that I'm implementing a payment gateway, is there anything I should be checking or verifying?
The way this processor works is, I build a form that has the order id, amount, currency, etc. in hidden fields. That form is posted to the gateway, which will handle the processing, and then post a form back to our server where we can update the shopping cart and complete the order.
The only thing I can think of is a user modifying the form fields before we post them to the gateway. Such as adding a $100 item and changing
<input name="amount" value="100.00" type="hidden">
to
<input name="amount" value="0.01" type="hidden">
So when I receive the post I have to verify that the amount paid for was equal to the amount owed. Is there anything else I am missing? The implementation documentation doesn't even mention a scenario similar to the above, so I'm a little worried I'm missing other things and leaving the site open to further exploits.
I think you'd be better off creating a dedicated web service to handle this '3rd party' conduit architecture you have going on here, your basically playing the middle-man and an HTML form just feels like unnecessary overhead to me, unless it's required to be done that specific way, I'd move to a web service.
That being said, treat it like any client application, don't trust whatever they give you, validate and cleanse the information as necessary before performing the operation.
I would also recommend building or integrating support for logging into your middle ware system, so should a problem arise, you have some way of capturing issues and tracking them for the future, bug fixes, support calls, etc.
It's probably obvious but make sure to validate your order #'s, a user could put anything in there they wanted, again, validate and cleanse the data and log the truly weird situations.
First, I have to agree with Capital G. It would be so much easier to just make a server to server connection than to try and handle form submission through the client browser.
One thing to check: after submitting to the gateway, does the client then initiate the post back to your server, or does the gateway server handle it? If the client initiates it, what prevents them from POSTing to you that the order is complete without ever having gone to the gateway? It sounds like you might need to make a webservice request to the gateway to verify the payment actually went through before accepting the client POST that claims it did.
Could you add a digest to the communication? If you had a shared secret with the gateway you could validate the integrity of information shared even if it passed through the client by including a digest both ways.
Make sense?
Carl
First, I don't think you're implementing a payment gateway. It sounds like you're just using one. If this is wrong, just ignore the rest of this answer, and I'll delete it when I can :)
Using a Payment Gateway from a Simple HTTP Form
Google Checkout -- as one example -- allows you to use an "unsigned cart" like the one you describe. The other option is to post via the web service interface, and do correct error checking etc.. When you submit an order with an HTML form, Google Checkout warns you, the merchant, that the "cart is unsigned" (later in the admin screen). This means that the information in the cart -- especially prices -- is not to be trusted. The fact that the end-user put in their credit card basically vouches for the fact that the transaction is okay with him/her. So you just have to check that the numbers used to arrive at the final totals -- or amount owed, or whatever your business is -- check out. So what you're doing is fine on a low-level.
The reason you should use a web-service submit to the service -- and secure signing of the cart, etc. -- is... What do you do if the numbers are wrong? Call the end-user up and explain the situation? So that's a bit tricky, because you cannot assume fraud. There are many strange reasons for which the cart would be altered without the user actually wanting to scam you.
the company I work for want to use a "hosted payment form" to charge our customers. A question came up on how we can populate the "payment form" automatically with information from one of our other system. We have no control over the hosed payment form, and we have to use IE. Is this possible at all? And if so, how can this be done?
If something is unclear, please let me know...
Assuming that you are essentially embedding the contents of a remote form in a frame/iframe, the you should be able to use some javascript to set values for the fields - field.value = "xxxx".
That solution of course depends on the form remaining the same - any changes to the remote form will require you to update your script.
If you are "handing off" to a remote site (redirect) that post's back to your site when payment is complete, then unless the remote site offers an API / a way of passing request parameters through, then you are going to be out of luck,
Unless your payment gateway allows you to pass through data in a set API (which lots do!), you'd need to take control (and responsibility) for your payment form.
I say responsibility because you would have to prove to your merchant account provider that everything is secure. This will probably incur some security testing fees too.
So check with your merchant gateway first. Lots of systems have the means to accept data from your site and their tech support will be able to give you a straight answer immediately. Otherwise you'd have to switch it over so you process all the data yourself which, just for making things easier, isn't worth it IMO.