I've got a frontend app that handles payments via Authorize.net. In the end, I've got a TransactionId attached to my own order object.
I would like to provide a direct link for my staff that takes them to the transaction in Authorize.net.
Our specific use case is for refunding, and I figured out this link in the sandbox: https://sandbox.authorize.net/UI/themes/sandbox/transaction/QuickRefund.aspx?TransID=1234567890
I would rather send them to the transaction, and let them click the refund button to get that page though.
This doesn't work: https://sandbox.authorize.net?TransID=1234567890
Anybody have any ideas? I could always write my own endpoint that does a refund via the api, but a direct link would be good enough and much easier if it exists.
This functionality does not exist. You will need to build your own endpoint that uses their AIM API to process the refund.
Related
I know this library flutter_stripe, which to me seems to be very limited in stripe interactions, it only does paymentIntent creation and that is basically it. Please do argue if I am wrong.
I am looking forward to see if there are other packages, if any, for flutter to interact with stripe in more depth, I am trying to avoid Android/IOS native languages.
I do these in backend: create stripe customer, create setup intent for each customer as they try or either add bank card or make purchase.
I am looking forward that client will interact to stripe for the following:
1 Confirm setup intents
2 Send card data to stripe
Another question, could you please assess my payment flow? If it is faulty please recommend another way
Once setupintent is confirmed for the user, they hit backend for whatever purchase they want to make, backend contacts Stripe, fetches the setupintent, creates and confirms the paymentintent.
Thank you, I appreciate help.
Your payment flow looks normal and it's basically outlined in Stripe SetupIntent Doc. The Doc only has Web/ iOS/ Android/ React Native, but the flow should be the same.
There is also an example inside flutter-stripe's repo for SetupIntent. Both resources should be enough well-explained reference for adapting to your implementation.
I have a FB page that is a member of about 10 groups (all related to the same topic), and sometimes when I post I share the post to these groups.
Since it's so tedious to manually share the post to each group, I thought maybe using the API could be a better way to share my post into these specific groups my page is a member of. But FB seems to require that I enter some business details for a business that doesn't exist.
I don't own a business, this is a page to share educational tips and such. So I created an app (kept it in dev mode) and I'm the only administrator. I don't plan to make my app public, create an interface or have anyone else use it, and I don't intend to use it with any pages other than mine. Plus, I've already provided my personal ID so I am verified as an individual:
But still, if I want to get manage_pages permission I'm required to go through some business verification and show FB how I'll use the API in a video, when I don't have any of this. In the verification page I'm requested to upload an icon, a privacy policy link and confirm commercial use:
Should I just make up some fake business information so I can give them what they want? Is there not a way to use the API for personal use?
I'd be happy with just being able to send a couple cURLs to share my post through a terminal instead of having to do it via the FB GUI.
The only requirement to complete review by business verification is to manage more than 3 pages per user, otherwise you can complete via individual verification. However you say pages and groups so it's not clear if you refer to publishing to a page feed or to a group (which requires additional permissions/features besides only manage_pages). And no, you shouldn't fake official documents just to complete business verification if you don't have a business...
Currently I set up a RESTful API backend using Django and I can list a set of articles by the following GET:
api/articles/
Also, I can get a single article by:
api/article/1/
Each article is owned by a certain user, and one user could have multiple articles of course.
On the frond end side, I present all the articles at loading of the page, and I hope the user who is logged in currently could see the articles that they own in a different style, e.g, outlined by a box, and has a associated "delete" or "edit" button.
This requires me to tell, after the retrieval of the articles, which ones are owned by the current user programmatically. One way of doing this is to check the current user id with the owner id. However I feel this is not a good choice as the user id is the check is done fully on the client side and may be not consistent with the actual server judgement.
Therefore, is there a way, to tell by looking at the response of the GET, (say, let the server return a property "editable=true/false") to get whether the current user could edit(PUT) the resource?
I understand that this could be done at the server side, by attaching such a property manually. However, I am just asking whether there is better/common practice.
I just started learning web development and I am sorry if the question sounds trivial. Thank you!
You can attach propriety manually as you suggested. The advance of this approach is that you dont need any other http request.
Second possibility might be, that your client intentionally request information about endpoint permissions. In this case I would suggest to use OPTIONS HTTP method. You send OPTIONS HTTP request to api/articles/1 and backend returns wanted info. This might be exactly what OPTIONS method and DRF metadata were made for.
http://www.django-rest-framework.org/api-guide/metadata/
I think that this is a very interesting question.
Several options that come to me:
You can add to the GET api/article/1 response a HTTP header with this information i.e. HTTP_METHODS_ALLOWED=PUT,PATH,DELETE. Doing this way helps the API client because it does not need to know anything else. I think that this is not a good approach when more than one entity is returned.
call to OPTIONS api/article/1. Allowed methods for that user on that resource can be returned but notice that, in my opinion, this approach is not very good in terms of performance, because it duplicates the number of requests to the server.
But what if the entity returned also contains information on the owner or it? can, in this case the client know which policy apply and try to figure out it by itself? notice that the policy can be obtained from another endpoint (just one call would be needed) or even with the login response. If your entities do not contain that kind of information, it could be also returned as a HTTP header (like first option above)
I am interested to add my service into the share functionality of the Google Glass, my flow is below:
1. Take photo / Record video
2. Share with -> My service
3. the photo or video should be uploaded to my site
Is this functionality possible? it is very similar to Facebook and G+ share options.
I will be happy to know how to do it, Thanks.
What you are looking for is what the Mirror API calls a Contact. Your Glassware can setup one or more Contacts, specifying what content type can be shared with you and/or if there are voice commands which will trigger the Contact.
You will also need to setup a Subscription which will be the public URL for an HTTPS enabled server that the Mirror API will use to send you the content that was shared with the Contact.
In general, the flow when a user first authorizes you to write to their time would be something like this:
Add a Subscription, so you can get callbacks.
Add one or more Contacts. In your example, you would want to register the Contacts to have acceptTypes of image/* and video/*, although you can also omit the acceptTypes to get everything (including text).
The callback you register with the subscription should be able to handle a JSON body, and should return HTTP code 200 as quickly as possible. A good procedure is to actually accept the body, place it on a job queue for processing later, and immediately return the 200 code. When processing the body, you may want to do something like
Confirm the userToken and verifyToken provided are valid.
Using the itemId, get the Timeline item, which will include attachment information about what was shared with you.
If the attachment is marked as isProcessingContent, then the content isn't ready for you and you should return the job to the queue and try again soon.
If isProcessingContent is false, you can use the attachment URL with the authentication token for the user to fetch the content itself.
There are a lot of details I've glossed over here. For a further overview of the flow, see https://developers.google.com/glass/develop/mirror/contacts
I made a Django online-store site and I need to include paypal checkout system for the cart, but solutions I found online either just for one item only(Buy Now buttons) or something like django-paypal-cart, which is not well-documented and I can't figure out how to make it to the checkout.
Please, give me some hint, maybe good article about how to make your cart items go to the checkout, anything will be highly appreciated, I don't know what else to google now
There are numerous options for tying PayPal into your website or app. Depending on exactly what you're doing or how good you are with web service API's you may choose one or another.
If you want to keep things simple, you can stick with Payments Standard. This is basically what you're referring to about the one item only buy now button, but you can use the cart upload command method to build a form that includes multiple items and pass it all over to PayPal at once.
If you prefer web service API's I'd recommend using Express Checkout. This consists of SetExpressCheckout, GetExpressCheckoutDetails, and DoExpressCheckoutPayment. Read through that general EC documentation to get familiar with the calls and how it all flows.
Another thing I would highly recommend utilizing is Instant Payment Notification (IPN). This is a feature where PayPal will POST transaction data to a listener script that you have sitting on your server any time a transaction occurs on your PayPal account. This includes payments, refunds, disputes, cleared payments that were pending, etc. This allows you to automate tasks like updating your database, sending out custom email notifications, hitting 3rd party web services, etc. and it happens in real-time, so it's very powerful.