My application uses Amazon FPS to charge a user. After setting up a pipeline and receiving a token, I then issue a Pay request with that token. The response contains a Transaction ID and a Transaction Status.
http://docs.aws.amazon.com/AmazonFPS/latest/FPSAdvancedGuide/Pay.html
Then I wait to receive an Instant Payment Notification, which has several fields, including the total transaction amount.
http://docs.aws.amazon.com/AmazonFPS/latest/FPSAdvancedGuide/APPNDX_IPN.html
For this transaction, Amazon FPS subtracts a fee from the money my account receives. I need to record the fee for the application's bookkeeping.
Where can I find the amount of this fee?
I could attempt to calculate it, but with rounding that seems error-prone. Additionally, Amazon's fee schedule varies with scale: higher-volume applications are charged lower rates. Attempting to reproduce that math accurately sounds like a disaster waiting to happen.
According to the documentation, no fee information is sent in an IPN - as you've discovered.
The only way to get the transaction fee is to call GetTransaction. This call returns a TransactionDetail which has an FPSFees property.
Related
I have a site that bills variable monthly amounts based on the subscriber's usage (typically $3 to $60). Currently, the 200 or so subscribers set up a monthly PP subscription that may or may not match their usage. I would probably use IPN to collect that info, but currently do it by hand.
I would like to use an API to request and receive the exact monthly amount. Which API? I have read elsewhere that Adaptive Payments may be the one to use, but is that appropriate/accessible to my business size?
Additionally, where would I post a request for a programmer for such?
You would need to utilize Reference Transactions for that.
Basically, you setup a billing agreement with the user an then you can use the Billing Agreement ID that you get back with the DoReferenceTransaction API any time in the future to process any amount necessary without further approval.
So you'll need to create your own system to automatically process payments on a daily basis as necessary, but this method will allow you to handle variable amounts.
If you're using Payments Pro you can do the same thing, but you don't do a "billing agreement". What you can do instead is run a $0 authorization, and then you would use the transaction ID you get back from that in the DoReferenceTransaction request instead of a Billing Agreement ID.
I looked over the documentation here https://developer.paypal.com/docs/api/ but I'm still not finding the right request that will return what tier of Merchant Rate a particular user has.
For reference: Paypal can charge $.30/transaction and (2.7%, 2.5%, or 2.3%) of the dollar-value of a transaction. I'd like to request the current tier a particular merchant is being charged so I can run an estimated calculation on newly authorized or pending authorization transactions in my app before Paypal actually finishes processing and charging the fee.
The other option (more painful) is to run a reverse calculation on the most recently completed transaction* to identify the most recent fees being charged, then store that as the current tier and update it on a schedule.
Anyone tried to get this info or found a workaround successfully?
*example calculation
If the most recently completed gross transaction amount was 100,
Fees charged were 3, net settlement was 97
Then 3.00 - .30 = $2.70
2.70/100 = .027
Therefore, current fee tier is 2.7 percent + .30
Then, I'd store that info.
This is more of a question regarding flow than code.
I'm currently working on a booking website for a holiday home. I've implemented a booking system which currently takes full payment at the time of booking. This uses PayPal REST API. It works fine no problems code-wise.
However my client would like the system to take a deposit when booking (20%) of the total. Then take the remaining amount later on (through the site). This seems strange to me and I've never used a website which does this so I'm not sure what the flow should be.
The only way I can think of achieving this is that the user has to come to the website at some point in the future to pay the remaining amount. I could send them email reminders but it seems a bit awkward to do that.
Has anyone done anything like this in the past?
In order to take the money later, you need to store the credit card data in your system, which is not quite legal unless you are authorized payment service provider (and I'm almost sure you're not).
We have the same case in our reservation system. Generally, you'd allow credit card payment only for deposit, and later final amount is paid via bank transfer or cash, for example, and has to be settled manually by an operator.
Your idea is not bad, however. You could inform the user about the final amount and due date in the booking confirmation email and later on send them reminders.
You can utilize reference transactions to handle this without storing/saving any billing information on your server.
Reference transactions can be used in Express Checkout as well as with Payments Pro.
Basically, the way it'll work is that you can process the original 20% and then you'll save that transaction ID in your database. Once you're ready to process the remaining amount you just make a call to DoReferenceTransaction and supply the original transaction ID along with the new amount to charge. PayPal will then charge this new amount using the billing information that they have saved on their server.
I'd like to store a Paypal transaction for a long term authorization (greater than 28 days) to be finally captured when an item ships. (That way, there's no risk as no money has exchanged hands at that point.) It's easy to do with credit cards by indefinitely storing the credit card via the vault and charging it when the time comes, but is there a method to indefinitely store a Paypal account to be charged when the time comes?
Right now, the only way I see that possible is through Preapproval in the Adaptive Payments API, but is there a method to do the same in the RESTful API? If not, is it planned? Is/will it be exactly like the current Preapproval API where it might fail because it uses the exact funding source or will it be more guaranteed? (I understand if a credit card is full, or user deletes their Paypal account, but that should be a very rare event.)
More Info: The full amount is known to the consumer in advance, the general timeframe is known to the consumer in advance but not the exact date, the event or item could be cancelled so authorizations could be voided (therefore no money ever exchanges hands), and the money will go directly to me and not in escrow or chained with any other Paypal account.
yes it is in the works. It would be more like a long term OAuth access-token than a vault id for credit cards - since it's a user's approval to charge their PayPal account in the future. I will try to find the exact release plan but AFAIK it's some time around July time frame.
I have a bit of experience setting up online payment systems that accept credit card numbers and then pass them over to a gateway for a one time payment.
However, I now need to setup a system that can handle automatic recurring billing - where a user provides their credit card number and is automatically billed on a monthly basis from that point forward.
I am wondering what the best way to approach something like this is? (I notice that Paypal Payflow Pro does have a recurring billing feature, but I am a bit unclear on how it works.)
Any advice on the best method / service / gateway for implementing recurring billing? If possible, I would greatly prefer to avoid keeping a local record of credit card numbers for repeat processing.
Thanks (in advance) for your help.
There's a midpoint between building your own recurring billing and Auth.net's ARB or PayPal's recurring billing (both of which have their disadvantages). There are a number of providers that handle all the details and complexities of recurring billing, and simply report the charges to your payment gateway for processing at the interval you determine.
The most critical piece to look at is which services to credit card tokenization and support credit card data portability - this will ensure that your customer data isn't locked in with a billing provider and that you can take it with you if you choose another provider in the future. This also means that these providers store the customer credit card data for you, so you can greatly reduce your PCI compliance.
Take a look at Recurly (Disclaimer: I manage their customer and technical support) and Braintree. Both services will handle your recurring billing, credit card tokenization, and support credit card data portability.
Recurring billing is easy to handle and offload to a third party if your recurring amount is constant (e.g. the amount a user pays never changes in amount or frequency). Services like Authorize.Net's Automated Recurring Billing (ARB) and Paypal Payflow Pro recurring billing allow you to have those companies handle the actual recurring payments which means you don't have to store credit card information on your servers or even do anything once the subscription is created through their APIs.
If your subscriptions will vary in terms of cost or frequency, you'll need to use a service like Authorize.Net's Customer Information Manager (CIM) to create payment profiles for your customers. Basically you're storing credit card information on Authorize.Net's servers and whenever you want to make a subscription payment you tell Authorize.Net to charge the amount due to that payment profile. The drawback to this is you essentially have to build your own subscription system.
You usually find the recurring billing features in middleware gateways like Payflow Pro. In that case, it is invoked by a variation of the API you use for card processing. You usually set up the time span between billings and they perform the billing. You usually then reconcile the billing with the report that your processor sends you each month. In some cases, the payment gateway will post a notification to you that the billing was performed. You still have to reconcile the payments with the processor report because sometimes the notifications fail.
Canceling the recurring billing is also another API call.
If your gateway doesn't have the recurring feature, you obviously have to set up the billing yourself. This of course leads to storing card info and so forth. In this case, you usually tell the processor that it is a recurring transaction (which the gateway will do for you) so you get a discount on the transaction fees.
First, let apend the statement above "...tell the processor that it is a recurring transaction ...so you get a discount on the transaction fees". The true cost of credit card processing is a percentage fee and a per item fee based on the type of card presented ( and some other factors I won't delve into here.) The point being, on a wholesale price plan, the price would be the same regardless of whether it was recurring or not because there are no special rates for 'recurring' in interchange. But I digress.
"Any advice on the best method / service / gateway for implementing recurring billing?"
Don't take on storing credit card data no matter what. You can't afford the liability.
The right choice depends on several factors.
As to credit card portability, has anyone gone to Wells Fargo/ First Data and gotten their data out? (Braintree ISO/MSP). I guarantee it won't be pretty no matter what so I would focus on the right long term solution, rather than the exit strategy, though it will certainly weigh in.
Here's questions that need to be answered:
How many transactions per month? For very low volume, maybe a few hundred, pick paypal pro. It's easy to get into/ out of.
Are people more likely to pay with consumer cards or business credit cards? Interchange optimization is important if business cards. (CenPOS automatically optimizes the transaction for lowest interchange qualification, paypal and authorize.net do not)
What methods does my client accept payments? self pay on internet only? Phone orders? Mobile payments (special events or retail)? Choose a gateway that fits all their needs.
Do you need to charge on specific days- ie the 1st and 15th? Or any time? If on specific days, how will you prorate? Check the answer against the gateway flexibility.
What happens when a card expires?
What happens when a transaction is declined?
Who will need to see the payment data for customer service? How will they access it?
Determine your needs, then figure out which ones meet them.
For the record, CenPOS is the most robust solution, but may require more steps to integrate since they are newer to ecommerce.
Disclaimer: I've been a business user of paypal and authorize.net for probably a decade and more recently CenPOS. I'm also an authorize.net reseller, and CenPOS direct agent.
Just a heads-up about Payflow Gateway's Recurring Billing:
Their Instant Payment Notifications (IPN) is a fantastic feature, but only applies to their legacy APIs. For the time being, THE ONLY WAY to be notified by PayPal of a successful (recurring) billing transaction, is by inquiry. You will need to maintain a schedule to inquire, and send an individual inquiry for each, scheduled recurring billing transaction, one at a time. PayPal will not notify you if, for example:
A transaction is approaching
A transaction has occurred
This transaction was successful
This transaction resulted in fault
A credit card is approaching expiration
A dispute occurred
... and so on.
In my opinion, this renders their service useless.