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.
Related
We have two .NET apps used to import customers and transactions into our db.
One is "client" app running on QB user's side another one is a small web service to interact with web connector.
We save all custmers and their "base class" transactions / changes in our DB and display on a web site. Users can see their transaction information there. Problem is that customer's balance does not always get equal to Sum(Amount) for their transactions. We already know that a customer can have a job (sub level customer) and count those transactions too. Still it appeared that a customer can get payment discounts and we needed to count that too.
What is a reliable way of counting customer's balance which always coinside with to their balance ?
I read a post about using Balance Detail Reports but I'd like not use it.
Thanks,
Vlad
It's hard to give a exact answer as there's a lot of little pieces that you may be missing, we don't know how you are calculating your totals so it's just guess work here. Here's a list of the transactions that I know of that effect a customer's balance, along with some things to look for.
Invoices can have a subtotal and sales tax which should both increase the balance.
Receive Payments can have discounts which should also reduce the balance along with the payment amount.
Journal Entries against Accounts Receivable for the Customer will either increase or decrease the balance depending on if it's a debit or credit to the AR account.
Credit Memos should reduce the balance.
Keep in mind there may be more than one Accounts Receivable account, so you need to make sure you don't filter for all A/R accounts on Journal Entries.
Your best bet to figure out what you are missing is to find a customer who has a different balance than what you calculated and review your detailed transactions vs. the detailed transaction for the customer in QuickBooks.
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.
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.
We want to add billing capabilities to our rails-driven web application. I've come across two plugins that do that - Service Merchant (which is free) and SaaS Rails kit (which costs money).
Does someone have some experience with these plugins (or others with the same functionality)? which one would you recommend?
Thanks!
I looked at both of them and unfortunately neither met my needs.
You say that you want to "add billing capabilities" -- but how complex are your bills?
Subscriptions?
Multiple subscriptions possible per customer at same time?
Any variable monthly costs? (eg the customer pays every month, but the amount they pay varies depending on something.)
Any additional items that aren't monthly? (eg setup charge, consulting, etc)
Billing subscriptions in advance? (like the phone company bills monthly service.) Or billing in arrears? (Customer uses service, then you bill them.)
There are very expensive companies you can outsource this stuff to (~ $25K - $50K and up for initial setup). Eg www.zuora.com
Or you can roll your own and charge the credit card using ActiveMerchant. Be sure to store the credit card info at your card processor (eg Authorize.Net Customer Information Manager).
If you're venture backed, then consult your VC for ideas. It may be worthwhile for you to outsource the whole thing.
If you're a lean startup, use one of the low-end guys if you have a simple subscription model. If your billing is more complex than that, the right answer may be to roll your own.
Low end subscription billers: Chargify, recurly, Google for "subscription billing"
No experience with those plugins, but I highly recommend using chargify to do recurring subscription billing. You'll use their rest-based API to create 'subscriptions' and it handles all of the charges, emails, and canceling subscriptions for you.
You'll pay chargify per user on a monthly basis (but it's cheap), and you pay the credit card processor, but there's no setup fees to chargify to get started.
http://chargify.com/