I am creating a very basic online store that allows users to buy and customize certain products. I have gotten the payment system working using Stripe, and all that is left to do is provide the seller with a place to view the completed orders (which should contain Shipping Address, order configuration, etc).
I expect that this app will receive very, very low traffic (it's more for fun than anything), so I do not need a super robust admin system. I thought it would actually be sufficient to pass order information to stripe as metadata, and have the seller view the order information on stripe. However, a potential problem I see is that there might be more data than the metadata limit (20 key/value pairs, 500 val limits). Would it be better to create an admin system on my side (using webhooks to notify the application when the payment has been processed)? Thanks!
Stripe is really only meant to handle the payments part of the equation. The order part is normally handled on top of Stripe (either in your own system or some third party), with that system linking order ids to charge ids.
Having your own order admin page would normally make more sense in the Stripe model, since Stripe only stores the amount charged and not much more.
Also unless you're doing subscriptions, no need to wait for a webhook. The Create Charge API is synchronous so you'll know when the payment was processed instantly.
Related
I am working on a SaaS system and while writing it, I was thinking about why I am duplicating the Stripe objects in my app? Why not just depend on Stripe to maintain all of those records. For example I have the models:
Customers
Subscriptions
Invoices
Charges
Payment Methods
Some of these (Customers, Subscriptions) are crucial to my app and must exist as they contain extra information about the object. Others, are just duplicates of the Stripe objects.
So my question is, in your architectures, why not just rely on API calls to Stripe to supply the app with data instead of depending on API calls and webhooks to maintain a consistent state between my app and Stripe?
I can think of a few ways to write this.
Create a model and store all fields in the DB. This is time consuming and very rigid (lots of webhooks to monitor and syncing to be done). On the flip side, almost all of the information I need is local and doesn't need an API call to work.
Create a model for all objects but only store a PK, a reference field to the corresponding Stripe object, and any "extra" data that is specific to my application. All data revolving Stripe would require an API call to retrieve.
Only create models for objects that perform logic in my app (Customer, Subscription) and load instances of children via API EG:
class Subscription
def invoices
Stripe::Invoices.list(subscription: self.stripe_id)
end
end
The big advantage to keeping some or all of this state on your end is that you don't need to make Stripe API requests to get the information, which makes fetching the information a lot faster.
Also, as your system and usage scales up, it won't be practical to make an API request to Stripe every time you need some of this info, as you'll start hitting rate limits.
Generally speaking it's best to strike a good balance between optimizing both the amount of data you store, the complexity of the logic you write to keep things in sync, and the number of API requests you make. The specific balance often depends on the unique needs of your particular system/tech stack/business/etc.
I'm making a site for a coaching company, and they've requested that we somehow keep card information on file (I informed them that that is a big no-no, and most payment API's will handle that side of things for us) so that we can charge the cards 'on-demand'. For example, the person shows up to a coaching session, types in a pin, and it charges their card for one session.
Best case scenario- this also works for an online store as well for payment processing. Once the card is on file, they can create a card, punch in their password, and they are good to go.
We are currently using Authorize.net with Ruby on Rails. I'm still fairly new to the development world, and this is my first time needing to handle payment processing. As far as I have seen, there isn't as much documentation as there should be. They would prefer not to use Stripe, as it has high per-charge fees, and most of our fees are $8-$15, and they also want to avoid PayPal, as it has been known to freeze accounts for no good reason.
Storing credit card information on your side is not practical for two reasons - security and cost (PCI compliance). Your best option is to use Stripe or Braintree.
Both offer great libraries and work as payment aggregators (no need for a merchant account with a bank to start processing payments).
https://stripe.com/docs/api#cards
https://developers.braintreepayments.com/ios+ruby/sdk/server/payment-method-management/create
For Authorize.Net, you would use Customer Information Manager for secure data storage. http://developer.authorize.net/api/reference/starting_guide.html#customerInfoManagerID
I am building a rails application for place booking. The app should be able to facilitate bank transfer (not VISA/Mastercard direct payment) for payment. Basically we let users know our bank account number. User can then pay via iBanking / go to ATM or Bank. Nah, when we received the payment, we should know whom this payment comes from and from which booking.
How are we supposed to know whom send it and for which booking it is, while there is no additional data in the transfer information other than amount of money. I heard we can apply a unique cents identifier, like when the payment is $8, we make it $8 2 cents to link it to the user who sends it and the booking data.
Is that the best practice in linking the actual payment data and the booking data? If it is, is there any ruby gem capable for generating the unique cents identifier? Or if not, is there any better approach?
Thank you for your assistance.
Bit vague, but a lot of companies that bill people, and allow the user to pay by bank transfer, require the user to put a specific reference number on the transaction, which ties the transaction back to that user's account.
It needs to be made obvious to the user (and it usually is) that if they fail to put in the right reference number then the payment won't be linked with them, and therefore won't show up as a credit on their account.
This doesn't feel like a particularly satisfactory system, as it puts the onus on the user to get it right or risk being charged extra for late payment, or have a hassle sorting it out. But, lots of successful companies seem to operate like this.
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 know it's possible to sit between a payer and payee using PayPal by just storing payee's PayPal account information.
Is it possible to take a percentage of the that transaction and pay it to a different PayPal account. Basically acting as a service fee for using our website?
If it helps, I would probably be using Active Merchant for rails.
What you are looking for is called "Chained Payments". You can take a commission from a payment, and the remainder can be split with one or more payees. The original payer only sees you. Chained payments are one of the several types of workflows you can get through the "Adaptive Payments" API.
More info on:
https://developer.paypal.com/webapps/developer/docs/classic/adaptive-payments/integration-guide/APIntro/
and pages 18 and 19 of the following manual on Adaotive Payments manual at cms.paypal.com/cms_content/US/en_US/files/developer/PP_AdaptivePayments.pdf
I was looking into this very same scenario, and I believe I've found that it is supported via PayPal's Website Payment Pro API. It appears as though there are several available use cases, such as:
Taking a cut, as you described
Dividing up a single customer payment among multiple payees (so if you have a shopping car where you resell items from several different providers, you can divide the payments up based on who provided each item)
Take a look at the document here and see if it fits your needs. I'd be very curious to hear how your integration goes, since I'm looking at something very similar for my forthcoming site.
https://www.x.com/docs/DOC-1328
EDIT: You should also take a look at the Adaptive Payments API. That was the other service I found that may fit this use case...
https://www.x.com/community/ppx/adaptive_payments
You can automatically charge transaction fees between the payer and payee if you use the Amazon Payment Service. It explicitly supports your business model.