So, i'm relatively new to Vue, and I'm currently using it to build a small app that displays order data from Square's API.
I'm currently working on a stack that uses rails to make api calls using the square.rb gem. The frontend is entirely Vue which uses Pinia as a store, and there isnt going to be any kind of database behind this because reasons.
All data is provided directly via Square's API. I am currently polling to update order info, but my client wants to make this app truly real time, as it deals with food deliveries through ride-share companies and the purpose of this app is to show in real time statuses of orders for an in house screen at the restaurant.
Now Square has a webhook subscription service, and based on my reading it sounds like I can consume these to update my app, but there are a few logical leaps that I havent been able to make yet with how to get that data to the frontend of my app.
My questions are the following, with the intent being to connect the dots between the different technologies I might need to employ here to make this work. Kinda get a sense of what i'd need and where to link it up.
Can I use vue to consume webhook payloads directly and update through reactivity? That would be ideal, but I have found no docs yet that give me a good idea of whether thats possible.
If that is not possible, do I need to use some sort of socket connection (socket.io) to listen for these webhook updates?
If the current setup or proposed setup in the questions above is not feasible, what is a better solution for handling this while still using Vue?
I work in a large enterprise where multiple teams are developing Lex bots (on separate accounts). Each bot supports a different domain or application,. In some cases, it would be nice for a single user interface to ask a question without needing to know which bot to ask. Is there a way to federate bots, or to forward un-recognized intentions to 'backup' bots?
I feel like what I really want to do is treat each bot as a skill is treated in Alexa, except I'm in the position (through entitlements) to know which 'skills' would be appropriate for a given user.
The answer here is that you would need to develop a custom application that delivers a user's input to each of your company's array of bots.
You'd need to look at the NLU Confidence score from each Bot's response to decide which response is the most accurate to return to the user. Would also be worthwhile keeping some state in your app to remember which Bot the user is currently interacting with and defaulting to that Bot for successive user inputs. Should you reach a point where the confidence score is low, it might present a signal to you to test the user's input across the other Bots.
What you'll need to be aware of here is that your costs will increase with each additional Bot that you add. So, assuming you have 5 area-specific Bots, one inbound message from your user could result in 5 Lex calls. As you start moving into significant volumes of interactions, this could start proving to be an obstacle.
An alternative would be to use a custom fallback intent to invoke a Lambda function that calls your Bot orchestration function. Assuming that you're able to find the correct Bot to handle the user's query, you'd need to remember that so succesive messages now get routed to that Bot.
First, notice I have read many post regarding this topic, but the info provided is not enough for me or is not accurate.
I´m developing a website with AngularJS and Ruby on Rails that offers different services. Users can subscribe to these services (one or many) and they get a Paypal Recurring Payment (through a profile) to pay these services (using merchant API). For a fixed amount the service is working ok for me.
The problem is, the amount can be different from one period to another, depending on the number of services the user is subscribed.
I have read Paypal docs, but It´s still not clear to me what is the right approach.
My approaches are:
Once a user subscribes a new service, I can remove the existing recurring payment profile (with fixed amount) and create a new one. This would be ok, but I have read I can´t delete a profile automatically from my application. I can only create. In order to delete an existing profile, I have to do it manually, by login in my business paypal account and delete it. If true, then this is not a solution for me, because I can´t do all flow automatically. However, this is quite strange for me. Is this true? If not, could you please let me know how to do it?
Although, I have not read deep on it, I read on a post I can use Reference transactions to implement this. Is this right?
UPDATE
https://developer.paypal.com/docs/classic/express-checkout/integration-guide/ECReferenceTxns/#recurringreftxns
As far as I understood, Reference transactions let me vary the amount to get from the buyer when I run it, but the problem is that this operation does not executes recurring (managed by Paypal). I should keep the logic in order to execute it from my application. Right?
Any other approach or clarification is welcome.
UPDATE
My first approach is to create just one variable recurring payment with the amount of all services subscribed. But, maybe the solution is to create a recurring payment profile per each service?
1) This is true if you're using Standard Subscription buttons, but if you're working with the Recurring Payments API you can cancel the profile using ManageRecurringPaymentsProfileStatus.
2) Yes, with reference transactions you can charge any amount you need to at any time, but it would be left up to you to build your own recurring payments system, basically, utilizing reference transactions. You could have a script run each day that goes through all your accounts and processes due payments accordingly.
Another option would be to have your users create a Preapproval profile and then use the Pay API to process payments using the preapproval keys. This is very similar to reference transactions.
I am developing something with ejabberd server. I came to the need of changing the subscription logic. I am using ejabberd-2.1.11
My need is on how the subscription works, I would like to change the logic so that users upload their roster contact with subscription both automatically and and save in in the rosterusers table-colum subscription immediately to be B. So that they should be able to see online and in their contacts at least when the first one has already registered to the server. ( hope this make sense for you and is valid)
I am a very beginner in erlang and ejabberd architecture but I have already developed some basic modules, my question to you is if you could help me on this regard, how difficult is to make this change and if you could give me some hints where the changes would be
I'd stay away from modifying the server, it conforms to standards and follows the specification. So if you ever need to move to another server or upgrade, you know it's just going to work.
What you would do to achieve this is implement this behavior on the client using the server's features.
If you are really sure you want to modify the server, mod_roster.erl is the file you want to be looking at.
If using an external DB, you can also modify the DB directly, but changes won't be reflected until the clients log back in.
I am in my sophomore year of programming in general and Ruby on Rails more specifically. I have created several apps and finally have one that I would like to start charging for. I have never implemented something like this before and I feel like (from what I have read) most of the docs provided are a bit over my head. I don't mind diving in but before I did I wanted to get some opinion from those more experienced about what is the simplest way to implement a model for charging my User a month fee for use. Two notes:
My App contains Users already and I will be introducing a new section of the app which I only want to give access to those who pay.
I don't mind sending them to a third party page for payment.
From what I can find, it seems like both PayPal and Chargify do a decent job of providing help for this type of integration. What are your thoughts about which type of solution is best for a newbie to this space.
I'll admit I'm biased since I'm one of the founders of Chargify :-).
But before that I helped build 7-8 companies, most recently Engine Yard, and I really, really wish we'd had something like Chargify back then. I remember thinking, "Man, we need something like 'Basecamp for Billing'... it should be simple, sign up with a credit card, define products & pricing, and get going". So I found the Chargify/GrasshopperGroup folks and joined the team.
Chargify takes it up a level from what we found with payment gateway offerings and things like PayPal... with Chargify, you define products, prices, coupon codes, metered-usage units, etc., and let Chargify do as much as you want. The system emails your customers when their cards get declined or expire, and directs them to a URL to fix the problem, etc.
Billing gets complex as a business grows. I tell callers that if their needs are really simple, then they may indeed be okay with Auth.Net's ARB service or another like it, but as soon as your needs even begin to get less simple (ie, customers change plans mid-cycle and want proration), then Chargify really makes your life easier.
And as Rails folks ourselves, we're always working to make the service better, so you'll get more and more services as time progresses. And you can actually call us 24/7 and get someone on the phone! Our Level 1 phone team knows the product better and better each week and can send the call to Level 2 if they don't know the answer.
So, you're getting a good piece of software, plus a good team who's here for you to develop new features and provide support if you need it.
Sorry this sounds like an ad; it is, partly, of course. But it's also just a reflection of my frustration trying to build this at earlier companies, and my enthusiasm for being part of Chargify now and helping merchants not focus on recurring billing :-).
http://www.braintreepaymentsolutions.com/
At a previous place of employment, we used Brain Tree, and I only heard good things about it though I wasn't (and still aren't, but trying) a programmer at the time. It seems to be a little bit more expensive than the big guys - but has more freedom as well.
It might be worth looking into.
Charging System or Billing System?
Talking with a number of folks building businesses in the Ruby community, I thinks it's important to note that simply collecting customer payments and scalable billing are two rather unique animals. Today's SaaS companies are not always aware of the difference.
Hitting credit cards for $39.95 on a monthly basis is something most of the "payment tools" mentioned here do well. Yet, when one needs to incorporate a complex billing algorithm (charge model), client contracts, promotional codes, freemium, tiered, rollover or metered usage, or integration with other internal systems, They need more than a payment machine. They really need a "smarter" billing system that leverages a payment gateway, but does far more than simply hitting cards on a monthly basis.
Also, if one has a significant number of clients or volume a system that scales is key. For research check out more mid-tier billing systems like http://www.metanga.com or http://www.zuora.com.
To take payment you're going to need a few things:
A bank account to put the money in
A payment gateway
An SSL certificate (this can be tricky if you're in the cloud)
The beauty of products like chargify or braintree is that they give you a nice API for dealing with card events like expiry or failed payments and can sometimes also act as a payment gateway.
I integrated with cheddar getter (https://cheddargetter.com/) in an afternoon. There's a ruby gem (https://github.com/ads/cheddargetter) and they have a payment gateway service, but I haven't used that so don't want to comment on its value.
Payment is an annoyingly complicated process and you have to pay everyone down the chain, the hardest part is making sure your service is competitively priced but not priced in such a way where you're not making any profit.
Here's some more links you might be interested in reading:
http://www.activemerchant.org/
http://recurly.com/
I've used PayPal's Express Payments with ActiveMerchant before, because there's no buy-in cost; PayPal just takes their slice of each transaction, so I don't have to worry about paying fees to a ton of different providers. The downsides are well-documented, though, as well - specifically, if PayPal decides that you're doing something shady and decides to freeze your money, you're up the creek without a paddle. That's a calculated risk you have to evaluate, though.
You might look at Saasy if you don't want to roll your own full solution, though. It seems to integrate well with existing apps.
ActiveMerchant is definitely the way to go to get integration with PayPal or any of the creditcard gateways like Braintree (highly recommended) or Authorize.net (good and cheap). The SaaS Rails Kit, which I authored, uses it as the basis for a full recurring billing solution that you can integrate with your app.
Regarding your follow-on question about PayPal, ActiveMerchant makes it easy to use their API or IPN to get information back about the transaction status.
I've had a ton of experience with this and the first question that you need to ask yourself is "how important is recurring billing?" If recurring billing is a requirement then by all means use Chargify, Recurly or the like. They are all pretty good.
If, however, you are simply looking to outsource your payment process (as I typically am) so you don't have to deal with PCI compliance (which is a nightmare) then you have a lot LESS viable options IMO. You can use PayPal, Amazon or Google Checkout, but they all have downsides. PayPals user experience is terrible and many people get confused by it believing they need a PayPal account to complete the purchase. Google Checkout REQUIRES the user to either have or create a Google Account, which is ridiculous and Amazon is ok but like Google Checkout requires an Amazon account.
WePay is my personal favorite right now for outsourced billing but is very lean and you have to use their checkout process. Their staff and API is awesome though.
What I would LOVE to see if a Chargify-like solution that is focused on ONE OFF sales. Something that let's me host the entire checkout process on THEIR PCI Compliant server but allows me to customize not just the look and feel but form. If I wanted to ask for extra info, like a username and password, I can. If I don't need shipping address, I can remove it. If I only want the CC number, CVV and exp date without billing address I can do that, etc.
But to the best of my knowledge that does not currently exist. Don't use Chargify for one-off transactions. While they support it the checkout process is VERY clunky for one offs (displays things like $0 setup fee, which means nothing when someone is buying a shirt or one time downloadable material and is merely confusing).
Good luck!