Yes, Braintree and Taxamo have a couple of widgets facilitating their integration, but the way they work they are tied to the process of authorization of a credit card while what the tax services are interested in are SETTLED transactions (i.e. what is actually billed from the client at the end of the day),
settled transactions aren't the same thing as authorized transactions, voids, IO problems in API communication, client-side software bugs, even credit card company policies (chargebacks, presentment rejections etc) result with what is authorized not being equal to what is settled / billed,
special world of pain continues when you consider the complex formulas for mid-cycle subscription updates (proration), discount and addon calculations and the fact that none of my subscription API calls done using the sandbox don't have a transaction object (so I don't know the amounts being billed from the client),
meaning I have to reimplement a bunch of advanced logic done by Braintree to deduce what the client will see on his bank statement and hope to have gotten everything right, or have IRS on our back -_- (in Croatia companies get blocked over 1-3 euro imbalances in the tax reports)
So the question, am I missing something here?
is there a simple way to submit to Taxamo only settled transactions?
does maybe the sandbox and mock webhooks behave differently than production, is it possible that Subscription API calls and webhooks in production return a transaction object and that I just don't see it?
does the current Braintree and Taxamo integration at least "kind of work in practice 100% of the time" and I'm worrying too much?
Full disclosure: I work at Braintree. If you have any further questions, feel free to contact support.
Braintree and Taxamo don't have an official integration package (the widgets available are not supported by Braintree, and Braintree had no hand in developing them). However, the two can be, and often are, used alongside each other. Because there's no official integration, the two integrations don't interact with one another, and the logic concerning when any action in Taxamo should take place in relation to an action in Braintree is up to a user to implement.
With that in mind, there's no 'out-of-the-box' solution to submit only settled transactions to Taxamo. Braintree does offer settlement batch summary reports, which contain the transactions that settle every night. Using the information there, you could submit your transactions to Taxamo every night alongside the settlement batches. However, be aware that transactions don't always settle immediately, so there will be a gap between the time that you submit a transaction for settlement and the time you submit the transaction to Taxamo.
Alternatively, you could store the transaction in Taxamo immediately and keep track of the transaction key that Taxamo generates to reference the tranasction. Then, if anything happens that prevents the transaction from settling, you can delete that transaction in Taxamo.
These are just two options to consider for an open-ended problem. As always, you should evaluate your business needs carefully, and do whatever you believe will work best.
As BladeBarringer mentioned in the comments to your question, the subscription response object does contain an array of transactions that you can reference. The most recent transaction is always at index [0] of that array.
Related
I have a User Microservice, that publishes events when a user is created, modified, or deleted. In addition, I have a Calendar Microservice that needs the user data. The Calendar service, subscribes to the user events and keeps a read only copy of the needed data.
I have just added an Account Microservice that needs the existing user data and I have used the same model as above. What is the best way to get the existing user data into the Account Microservice?
When I did the first Microservice I republished the user-modified event for every user. It was simple, because nothing else was using this event. If I republish now, for the new Account Microservice, the existing Calendar Microservice will also get the events. My logic is idempotent, but this is a lot of wasted work and will only get worse as I get more services.
I've loaded data a lot in the past. I know how to make it work, but I am looking for a best-practice and a way to do it with minimal coordination and dependencies with other services.
When I did the first Microservice I republished the user-modified event for every user. It was simple, because nothing else was using this event. If I republish now, for the new Account Microservice, the existing Calendar Microservice will also get the events. My logic is idempotent, but this is a lot of wasted work and will only get worse as I get more services.
What you probably want here is a design in which you pull, rather than push, copies of the events to new systems: see Greg Young, Polyglot Data.
In broad strokes - the subscriber keeps track of the high water mark, and asks for more events after some mark, and then the event store answers that query with zero or more new events, in order. The twitter timeline api can give you a sense for how that might work -- sadly, the images that explained the ideas seem to have been removed from the docs, but some of them have been captured here at stack overflow, and by the wayback machine
Is there a way to avoid race conditions when inserting events into Google Calendar using the API? I have an experimental app that needs to insert events into user's calendar. However, the user should not be double booked at a particular time.
The only true way of guaranteeing something like this is if Google provides a way. Other solutions are prone to race conditions (example, some other app that the user has updating it while my app is ignorant). The options as far as I can tell:
E-Tags with If-Match option - But this option is not valid for inserts according to the docs (https://developers.google.com/google-apps/calendar/v3/version-resources).
Important: There is no support for conditional modifications for
insert operations. Instead, it is guaranteed that if you are allowed
to provide a resource ID, then the operation will only succeed if no
existing entry has that ID.
So if I provide an if-match with the calendar etag and try to insert, it always fails regardless of the fact that the etag is correct.
Using "watch" for a brief period while the event is about to be inserted (https://developers.google.com/google-apps/calendar/v3/reference/events/watch). However, this solution is prone to race conditions due to the time take to get notified. One user inserting while my app gets notified of the update is problematic.
Sync the whole calendar with server periodically and consider the source of truth as the synced version and avoid double booking. Less optimal because new events added won't get synced fast enough, but the most likely will work.
What other solutions come to mind? I think #3 is the most suitable to guarantee consistency and integrity of data to avoid double booking.
I found a solution to this on this blog which states that you'll be using Calendar Resource API instead of the Google Calendar. I think this guide is what you're looking for.
Unlike a regular calendar, resources:
-Do not allow conflicts
-Can be shared across everyone on your Google Apps domain
-Can be invited (multiple at a time) to events, just like a person
-Their ability to share availability with everyone makes resources great for managing rooms schedules. Especially in a shared work
environment like your office.
FYI: This guide assumes you already have Google Apps. Currently only
paid accounts have access to resource calendars. If you’re
grandfathered in or using a personal Gmail account, this process won’t
make much sense.
I am currently using Kinvey only for the business logic. Everything else I am using other services. It seemed that I must be logged in to use business logic so I made one account and made the user register to that account when opening the app. I am confused if that will be an okay approach since I believe I saw on another post that after so many downloads, it will raise a flag on Kinvey's side. Is that true? I also just saw these images in the users section and am not sure what this means.
[
[
To answer your question about pricing, you can review our pricing plans at https://www.kinvey.com/pricing/.
Kinvey monitors customers in the free developer plan to check if their usage exceeds the limits. We do this by checking API calls per month, number of active users, data/file storage used etc for your kid - not by App Store downloads.
If that happens, Kinvey support or sales will reach out to you to help you transition to the next pricing tier or help you to reduce your consumption with optimization or other options.
Your queries about master secret, authentication are best answered in this Kinvey security guide: http://devcenter.kinvey.com/rest/guides/security
Regards,
Wani
Kinvey Support
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.
Our Magento store uses the Website Payments Pro payment gateway through PayPal. For the most part this works pretty well. Occasionally (about once a day), we get failed transaction emails and the errors are very generic (i.e. "Internal Error" or "There was an error processing your order. Please contact us or try again later."). I've been working with our PayPal rep, but he has not yet been able to figure out why. This doesn't happen with every transaction, and typically if the customer re-submits the order it will work the second time. This has been very frustrating for me as the developer, my employers, and the customers who see the same generic error message in a popup dialog box.
My questions are as follows:
Is this normal for a site that gets about 300+ orders/day?
Are we at the mercy of bugs in the PayPal system?
Do any of you have experience with similar problems? Or, on the contrary, do you have experience with a site that gets at least as much traffic and never has any errors with PayPal?
I'm at a loss for what to do. I want to believe that it is not an error in what we are sending to PayPal. But if every client using PP as their gateway experienced this much pain I would think someone with a loud enough voice would be pushing for improvements. I don't have any experience with other payment gateways, so perhaps PP is the lesser of all evils...
you certainly need to be prepared for issues like this and error messages for clients need to be clear and informative what to do if error happens.
yes you are and this can't be only paypal issue this can be n of issues with network latency user interaction etc.
there are n amount of sites experiencing this as the system is engineered with lot of break points and you can't assure that issues do not happen on 3rd party system or sites and you can have several precautions to avoid that by doubling the payment methods with several gateways etc.