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.
Related
Looking for best practice and/or improvements on logic.
I’m building an app where a member accepts a bid from a guide on a trip and pays for it. Depending on the situation, the member may pay a deposit at bid acceptance or pay for the whole trip (depends specifically on guide's settings and trip cost). I’m trying to determine the best way to determine what charges have occurred and what charges need to occur in the future.
My thought is to create two tables: charges and payments. Charges will track the successful payments. If the first payment is a deposit then a record will be created in the Payments table with the remaining amount to be paid and due date. This can then be charged in the future.
Is there a better way to handle this? Thanks in advance.
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.
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 have a requirement to make ad-hoc charges to users credit cards. As I don't want to get anywhere near having to worry about credit card storage and all the associated stuff that comes with it I'm looking for a middleman service that would handle all this for me, ideally supplying me with an API that I can use to add/remove cards, and make charges through.
I don't need recurring billing or anything like that just a simple card store for ad-hoc charges.
Does anyone have any recommendations based on previous actual experience, or know of any that are worth looking at?
Authorize.Net's Customer Information Manager (CIM) does exactly what you're looking for.
I have a client who recently changed the scope of a project I was building for them, to a marketplace.
Previously users had to pay a nominal fee to register for the site...I was handling credit card transactions using Active Merchant.
For the marketplace that they now want to build they want to build a simple escrow-type system...the payment to the seller gets released when the buyer receives the product.
This will be difficult for several reasons:
How will the system be able to determine when the item has been received? The receiver could simply lie about it. I know paypal does something similar, but they use the tracking number from the shipping company to determine this.
How do I go about depositing payments in the sellers account? It's easy to process the payment from the buyer, but how do I get this money to the seller?
For #2 I was thinking it might be possible to use some sort of paypal account to handle this...I haven't looked into any specifics yet. Any idea where to start?
Paypal may be able to handle #1 as well, if I am lucky.
Any suggestions?
We used PayPal Adaptive Payments for #2... still hunting for a solution to facilitate the transaction between User A and User B with the marketplace taking a %...
Would love to hear more answers!
In regards to #1 - I'd require some sort of signed receipt on delivery. That would depend on the value of the goods, at the lower range tracking receipt + some sort of reputation system to remove people who abuse the system has worked for me in the past.
In regards to #2, disbursements; I'd recommend you look at our product Balanced. It's built to solve exactly this problem so I think it's a good match.
Balanced will allow you to collect funds into an escrow account and then disburse the funds as a separate action which allows you to split the funds up or group them together as required. Payouts are done via next-day ACH (US only) but we're building out international support.
Balanced has an excellent ruby gem since you're building in Rails and there's an ActiveMerchant plugin if that's what you are/have integrated with.