I am currently working for an online market. Once a customer completes an order, I want to transfer that order into Sage Accounting using Sage API calls.
Here is how I have thought about implementing this process:
Customer sends an order
A script is called, taking the order details and creating an invoice through a sage API request.
My problem is that I cannot find a way to automatize the process before making the API request.
Here is how a request must be made (according to the Sage API documentation)
https://sageone-uk-help.s3.amazonaws.com/sageone_oauth.png
.
I am aware of the refresh token, but the problem is the code needed to obtain the access token is generated after logging into Sage. The script will therefore do nothing if it reaches the login page.
I'm very sorry, but it is not possible to automate the authorization process. It wouldn't make much sense as well: The Sage Accounting user has to explicitely express his consent that your application is allowed to access their accounting data.
If it's only one account your application has to use in Sage Accounting, you could just create an access and refresh token on your machine and export it to the application. Or you implement a "Connect with Sage Accounting" button in your application's backend which initiates the OAuth flow and then stores the tokens.
(And just for the sake of completeness: The authorization code is only valid a minute, so better not try to store that one anywhere.)
Related
I'm new to webhooks and am not really getting the hang of some points of it. KISS; the current problem is, think about:
a platform
that provides a service X
to book a service X, customer Y has to pay in advance
every payment is authorized first only
every payment is captured after the service has been received
From the booking of a service to the capture of the related payment, only the authorization is handled involving the client-side. All the rest is handled on the server-side.
For every possible case of a booking of a service on my platform, payment authorizations is requested as the first action on the server-side. Adaptations of the DB of the platform are only executed after a successful authorization of the payment from the frontend.
The only fallback webhook I implement is for the case where a customer books a service, authenticates, and then loses connection. Because in this case, the customer would have booked the service, but the platform server could not make the related updates. So the customer will have paid, but not receive his / her service via the platform.
My strategy is thus to implement a webhook to listen for the event of a transaction authorization "completed", and, if no transaction data is found internally, execute what needs to be done.
BUT, two questions popped up:
A) How can I control that a webhook gets executed AFTER the regular server-side script should have been executed? Delay the execution of the webhook script? What are the best pracs here?
B) If A) is possible, isn't it smarter to just cancel the authorized payment in the webhook, instead of coding the completion of every possible transaction via webhook? Already the thing that you lose the entire payload in case of a client who lost connection (the payload that you need to execute the server-side tasks after a payment authorization), and the consequent need of passing the according payload back-and-fourth to your payment API, while ensuring that CID is encrypted etc.; this just sounds like overkill to me.. Was anyone in the same situation, and also decided to just immediately cancel the just-authorized payment in lost connections via webhooks? Or must webhooks generally execute the exact same server-side script that the related server-validation would do? Meaning I have to find a way to pass the payload to my webhook function?
The webhook is your notification that the event has happened - you're under no obligation to perform any processing right that moment, or ever.
If you're using webhooks as a backup to a primary synchronous flow (a good design!), then you can record the event and enqueue for later.
Stick a record somewhere indicating "got this authorization. Check this again in an hour to make sure the customer did the thing."
And to your comment above: you probably don't want your sync and async flows to be the same. Your async backup might involve contacting the customer eg via email, while that's not necessary for the sync flow since the customer is still on session.
I am building a (small) subscription box business and I now need to focus on the web app. I already built stripe-based websites so I have a decent knowledge.
However, the issue I faced when building these previous sites is that the API was called TOO OFTEN. It slowed everything down.
How to build this subscription-based website, only with stripe, and making calls to Stripe API only when required (create/edit a customer, plan, subscription, etc.) while still making sure information is reconciled and up-to-date on the website for both admin and clients?
Check out the Stripe Webhook API here: https://stripe.com/docs/webhooks
You can store the user's information in the database and only update those fields if the user makes a UI action and you can make an assumption on what to update (like a subscription plan ID) or using a webhook handler, which you can use as a sanity check as well.
To be even more specific, I can give some examples as you will still need to make API calls when a user does an action such as: creates an account, removes their subscription, subscribes to a different subscription. You will store when their subscription expires in the database. When the user makes a request you do not make an API call to check when their subscription expires, but check the database field. When the subscription renews itself you will then have a webhook handler to update the expiration date in the database.
Essentially how it works is Stripe will make a request to YOUR service only when it needs to, instead of your service calling to Stripe on every request.
For WordPress specifically you can user the User Meta Data to cache/store the user's information and only make calls to your database for faster transactions. http://codex.wordpress.org/Function_Reference/get_user_meta
I am saving credit card info to the paypal's vault by using REST API. It gives me a token by using it i can make process further. But the problem i have to use paypal's button [ButtonSource] that is tracking total sales via paypal. So how can i use both ?
one other thing by using token i am able to get all details of card that is saved. In case if my code will be compromised then any one can steal my tokens saved in database and get the details. How can i make it secure ?
Thanks
Here is some feedback from PayPal on this one:
The Parameter ButtonSource is a parameter of our classic API's and is currently not supported with the REST API. The Rest API's are still in early stages and we will see much more Features added over the next 12 months. So even the parameter might not be supported with REST now, it can be soon. However, with REST as of now, the merchant would need to use other parameters to track his payments.
one other thing by using token i am able to get all details of card that is saved. In case if my code will be compromised then any one can steal my tokens saved in database and get the details. How can i make it secure ?
Technically, if the merchants System is hacked and his credentials + DB is exposed to a third party, they can lookup details using this API:
https://developer.paypal.com/webapps/developer/docs/api/#look-up-a-stored-credit-card
However, we won't return the full card number and the CVV is not stored on our end as well. So from that perspective the merchant is grand. However, they need to make sure that their credentials are secured and not accessible for third parties.
I was following these articles: Verifying Back-End Calls from Android Apps and Stopping Vampires using License Verification Library (from 24:57 to 25:34) to implement an In-App Purchase verification system for our Android apps.
I am a bit confused about how this works end-to-end and what we can assume about the generated token from calling GoogleAuthUtil.getToken() with the first email address found--when AccountManager returns more than one account. My questions are as follows:
Should we assume that any e-mail address used by the user to buy our
app will generate the same token (i.e., same user + app ==> same
token)?
If the answer to question 1 is no, is there a way to launch in-app
purchase for a particular account/email?
It looks like Google is picking the first e-mail address returned by
AccountManager for its in-app purchase dialog. Can we assume that
this won't be changed by the user after in-app purchase dialog is
launched? How do we find out if this changed after the in-app
purchase returns?
What should we store in our database to identify this user? Is email
address and/or token allowed? When does the token expire?
The java-client library looks very promising and powerful at first
read. But, a number of things remains confusing. Is there an article
that describes the end-to-end scenario--from an app initiating a
call to a back-end server through launching the in-app purchase
dialog, getting the result and closing with commits on the server?
What articles are the most useful for accomplishing this on Android?
The main issue we are trying to solve is to to get the full picture.
We've gotten the idea that we can avoid requiring userid/password by using the java client features and using tokens. We have registers our project (both the web app and android app on the same project) per the instructions for Google API Console. We have the php java-client for Google Play Service on our back-end server. We got our Android app to generate a token using the first email address and then call the in-app purchase dialog and handle the user response at the end of the dialog. We've got the parts. Now, we need to glue everything together. We are at the point of integrating with the back-end server. E.g., What is Redirect URi supposed to point to in our server? We've got a php url that we do http post messages to for our server app. We've included the code example for Google API client example--with client-id, secret, simple api key, etc. filled in--as an include to our php. But, what should we put in the redirect uri (we are missing a usage instruction for the example code)?
Also, we want to avoid having the e-mail used for the in-app purchase be different from what we log on our server database as the address the user used to buy our app; if the address is the correct thing to track, we want it to be the same as what was used for the purchase. This could be frustrating for our user if we make this mistake and prevent them from the features they paid for. We don't want to make this mistake and need some clarification on how Google Play Service works. If we initiated the server part of the workflow to get app Nonce / Payload / Credentials for the first e-mail address on the Android device, we would want that address to be used throughout the workflow. If the user changed this along the line, we want to be aware of this and gracefully recover. So far the articles have been helpful but incomplete. Any insight/suggestion is appreciated.
I want to create a credit card payment processing section in https://www.realcredit.com/ for my site. The users are allowed to access a page after payment has been made. What are all the steps needed to create a system like this. If anyone worked on credit card processing in Realcredit for a PHP site, guide me to implement the credit card processing section.
First you should specify if that payment is for a one time service or some sort of longer subscription/license.
If it's just a one time payment you might want to create a system where one can access the page using a single-use token. (You visit the page with an appended security token on the url and your session gets validated and the token invalidated.)
Then implement the payment system according to the API of realcredit.com and once the payment has cleared send a mail to the customer (or if clearance is instant display a page) containing a link with such a one-time token.
If you want to implement something like a license system then you might want to first implement a user-login for your page or a user database. Then once the payment has cleared set a flag on said user-record in your database allowing access to the page you want to protect.