I'm new with using payment processors, I'm building a platform with Laravel to facilitate business between clients and manufacturers. First client pay for the job to be done and when the job is done we pay the manufacturers.
I'm using Stripe to charge clients and it works fine. However I'm stuck with the process of paying the manufacturers. because Stripe is not clear on how to do that.
please if you have a solution with or without stripe I'll be very grateful
It sounds like Stripe Connect is what you're looking for. In this scenario, the client would be the platform account and the manufacturers would be the Connect accounts. Since you want the payment to the manufacturer to occur both after the job is done and after you pay the the client, you could use Separate Charges and Transfers.
Related
I have an application for various platforms. Let them be iOS, Android and Windows. In order to use a app, a monthly fee needs to be paid, but it just needs to be paid once in order to use all platforms. It is the same as with Spotify, so by paying once, every platform can be used.
According to the guidelines of Google and Apple, I need to offer In-App Purchases for the monthly fee. The system is connected to user accounts, which are managed by a server, which is in my control. I am storing the subscription data of users, so if a user uses the In-App Purchases on iOS, the information is transmitted to the central server in order to unlock the Android-App as well (in case it has been paid on another platform already)
The problem is the following scenario:
A user has a valid subscription which has been payed via Google Play. The iOS and Windows apps are unlocked as well. Now the user uninstalls the Android app, goes to the Google Play website and cancels the subscription. In the current scenario, I am not able to detect this and the subscription will be valid for all other platforms.
The question is:
Is there any pattern to circumvent this problem? Spotify and co are solving this issue as well, so there must be a solution for this
Well, the server that handles the authorization of the user (that is, your server) should query the Google Subscription API, to check if the current subscription is still valid. Each SubscriptionPurchase Resource contains information about when the subscription expires.
(see https://developers.google.com/android-publisher/api-ref/purchases/subscriptions)
For Apple, the same stuff applies: You will get a receipt, and with that receipt, you can query the server at any time to check if that subscription is still valid.
There is a slide which summarizes these points and the pitfalls very well: https://speakerdeck.com/rosapolis/the-recurring-nightmare-cross-platform-in-app-subscription-purchases
Bottom line: You won't be able to make that happen without a server that does the communication between the two stores. It comes with issues, though, as the slide shows.
Bonus: The talk from which the slides are taken is also on Youtube
Looks like you can add sms to existing toll free phone numbers but keep voice with the existing carrier. Is this possible with a regular landline without porting to Twilio? How can other companies do this (zipwhip)?
They work through an inter-carrier vendor like TNS, Aicent, or iQuall. These vendors basically all do the same thing - which is to provision and store SMS routing instructions for all US-based phone #s... these are all aggregated in one big central repository.
Example: if you're on T-mobile, whenever someone texts your phone # (from any carrier or platform) it hits this routing network that tells the message to get posted to t-mobile. Companies like zipwhip do the same thing, they just tell the network to enable SMS for that landline number, and the instructions just tell the network to point any messages back to their cloud.
This is only possible because the overall telecom industry agreed to support intercarrier messaging back in 2001. (source: CTIA)
Twilio has a private beta for routing SMS from toll-free numbers. You can DIY, just a little more work.
Updated answer: it is now possible to SMS host an existing landline, toll-free, or in some cases an existing VoIP phone number via Twilio. The voice routing and voice provider will not change.
Note that you cannot "roll your own" functionality today to make this happen because you need permission to write to the NetNumber database. And you're not going to be able to get permission to do so as an individual.
I am using the Plaid API for iOS to write a program which accesses banks accounts after authentication and displays the transaction data.
I need to know if it's possible to transfer funds between accounts (checking to savings) and how.
I know acorns uses the same API, and they are able to transfer funds, and Plaid's site claims "Authorize ACH payments in seconds based on the information users know in their heads. No need to know account or routing number. No need for micro-deposits."
But is there documentation on how to move money on the site?
Plaid does not move money via their API.
UPDATES
Dwolla now provides a white-label solution that basically does this all for you. Combine Plaid and Dwolla, and you're basically golden for payments in the US now.
Disclaimer: I co-founded a company that is a customer of Dwolla and one of their first white label customers.
Original content
Moving money with the credentials that Plaid provides requires using the Automated Clearing House (ACH) process in the US.
What won't work
Ripple Labs (currently under federal investigation), Dwolla, BitPay, etc. all require proprietary authentication with their own platforms before they will move money. You can't use them with the routing and account number that you get from Plaid. You have to adopt their entire system...or nothing.
What will work
Plaid's API provides more for you than those other APIs because you have the routing and account number. This allows you to directly enter into the ACH system yourself. All you need to move money is the senders routing and account number, the receiver's routing and account number, and the amount. Plaid gives you 2/5 of this already.
But you need to move the funds. Using an ACH processor (like Vericheck - I was a customer), you can use their API to send money to an account. Or a bank (like Silicon Valley Bank - also was a customer), where you can generate and upload a NACHA file with the instructions.
What you're in for
Compliance and banking laws are strict. Get a good lawyer to help explain what you're up against. ACH processors will want to do comprehensive background checks on you and your business. Banks will require you to deposit a portion of your proposed transactions to cover STOP payments (when a user tells their bank to cancel a payment, like voiding a check). You may have to register as a money transmitter (a small $1M in filing, registration, and legal fees for all 50 states).
Moving money is still difficult to do on behalf of a user, but if you're willing to put in the legal work, the programming is pretty simple!
Plaid's API actually will give you routing and account number information and/or transaction data with cool info like GPS coordinates of transactions but I believe when I spoke to them they explicitly said that they don't provide money moving services in their API.
I've been looking at Ripple Labs, Dwolla, BitPay, etcetera.
If you have any recommendations about getting Plaid and Meteor working well together, then I can add you to a Cloud9 workspace and would be delighted to learn. :)
Plaid recently signed an agreement with Stripe. Stripe allows you to move funds via ACH through their newly realeased API: https://stripe.com/blog/accept-ach-payments
This is very similar to what companies like Peloton Technologies Inc. have been doing in Canada for EFT since 2010. EFT is what most parts of the world refer to as ACH.
Plaid provides Stripe with a higher possibility of being able to instantly verify a bank account, otherwise they fall back to the old Paypal 4 day verification processes of issuing a couple of transfers and waiting for the users to verify the amounts.
The pain of waiting on the user and the fact that 7 out of 10 times a bank account is entered wrong is what has probably prevented Stripe and other companies entering this space until now.
Does anyone have any idea of the average Adaptive Payments application approval time at the moment? It appears there may be a backlog as we've heard nothing from the moderators and it has been over 15 days (their usual timescale apparently). Our case is a crowdfunding website built on CodeIgniter with the Adaptive Payment gateway installed and ready to go live when we are given application approval. Our site has been active for 6months using other methods via PayPal, but it's time to move up a notch.
It depends on the permissions your application is requesting; less restricted permissions usually goes through quicker.
Even so, check with PayPal Developer Technical Services at https://www.paypal.com/dts/ if you're looking for an update.
Please note: We are using Magento's Professional Edition which does not come with Vendor Support.
I've looked over previous questions, and while I can find questions and answers about multiple payment gateways on a site, I can't find anything about Magento's Payment Bridge specifically. Payment Bridge is a PA-DSS certified application that Magento provides with it's Enterprise and Professional licenses. It's necessary for a PCI compliant environment.
Our problem is that our client has two Auth.net accounts. This is for reconciliation and the explanation can get long-winded, so please just trust me that this is a necessary scenario.
When creating the merchant with the Merchant Configuration tool when setting up Payment Bridge, it only allows you to provide one login, i.e. just the one account, and it asks which cards are accepted. The site will accept all cards, but one account handles Visa, Mastercard, and Discover, while the other handles all Amex payments.
How can I set up the merchant during the Payment Bridge set up to be able to have both accounts?
Update - for now, we've created a hack in the Payment Bridge Authorize.net class that checks the card type and, depending on the type, it switches the credentials if need be.
Not a perfect solution, I realize, but it's working while we figure out something a little more stable.
If you have any ideas, please share!
Thanks.