I want to know that, however the reference transaction must have occurred within the past 730 days because the Billing Agreement ID may not be available after a two years. So if first transaction is done before expiry lets say after 600 days so the ID will be available until 130 days or it will again available for 730 days?
If you have the billing agreement id then its valid untill you or your customer cancels it . So its best practice to use the BA id for PayPal transactions .
For direct credit card payment you have to use the transaction id(as BA id is only if some one pays via Paypal).
Whenever you use the reference transaction on an existing transaction, the resulting new transaction id will have the new validity for another 730 days and this way you won't have to worry for 730 days limitation. So it's best to update your database with the latest transaction id whenever you do the reference transaction .
https://developer.paypal.com/webapps/developer/docs/classic/express-checkout/integration-guide/ECReferenceTxns/#id094TB0Y0J5Z__id094TB4003HS
Related
I was helping a customer figure out an issue and creating test invoices in the sandbox.
After the 4th one I started getting this error:
{
"name": "BUSINESS_ERROR",
"message": "Number is too long.",
"information_link":
"https://developer.paypal.com/docs/api/invoicing/#errors",
"debug_id": "2ca1d32e1fed3"
}
What number is too long? I've tried looking through all the info and nothing appears too long our out of spec.
Hopefully somoene at Paypal can use the debug ID to track this. This test program has worked without issue for months.
So, after dealing with PayPal support the number that is too long was the invoice number.
When I started my testing in the sandbox I always had PayPal auto-generate the invoice number. It gave something like:
INV2-UR7F-35N45-DGQZ-BYDE
So, after a few tests, the invoice number was incremented (by PayPal) and eventually reached:
INV2-UR7F-35N99-DGQZ-BYDE
Now, on one more call the invoice would be incremented to:
INV2-UR7F-35N100-DGQZ-BYDE
Which is 26 characters, and the maximum length for invoice number is 25.
The solution? I was told to use smaller invoice numbers. ;)
I feel this is a possible bug in the auto-incrementation of the PayPal Invoice, but I am posting this so when others run into this they know what to do.
What I did was in my sandbox account call the Create Invoice Draft API with an invoice number like "Test001" so that there will be plenty of increments left in the invoice number. After that call there should be no need to supply an invoice number, at least for a very long time.
I am using transaction search to return a list of transaction. With refunds it is returning two lines the refund and the fee reversal. There is no detailed info available for the fee reversal transaction, so how can I associate the reversal with the refund?
Use the oarent_txn field. It refers to the txn_id of the original transaction which has been reversed, and which you have already received and should have saved.
I have, in my opinion, pretty complex order case to implement. Paypal was choosen as a solution, but I can't figure it out how to implement it properly using express checkout (or anything else, but I am not sure what is proper to use).
Final order that can consist of (most complex example here):
subscription A with 1 month free trial - 100$/year
subscription B without free trial - 200$/year
initial payment for entire order - 50$
Requirements:
start of the whole order can be postponed due to some factors (I can set PROFILESTARTDATE to the given date)
all subscriptions in the order can be either monthly or yearly, so case where subscription A is paid per year and subscription B per month IS NOT ALLOWED
whole order must be processed in one paypal redirect (paypal page with products listed where client can login to confirm the order)
My problem:
in that order subscription A starts 1 month later than B but I can only set one PROFILESTARTDATE
I could use TRIAL*** parameters (like TRIALBILLINGPERIOD) for subscription B but I can only set one such parameter per paypal request for express checkout, so same problem as above
What would be a best option for such case ?
I noticed that for an account A, the lastTransactionDate is the date such that all transactions happen before that are available through getAccountTransactions. It's NOT the date such that ONLY all transactions happen before that are taken into account when calculating the balance of account A because some transactions happen after lastTransactionDate have to be taken into account to yield the correct balance. Can someone confirm my observation?
Another thing is that some transactions that happen on the same date as balanceDate with the exact time being AFTER the time of balanceDate are taken into account as well to yield the account's balance. For example, balanceAmount = 7682.16, balanceDate = 2013-08-06 12:53:21 - 07:00 but the transaction with postedDate = 2013-08-06 16:49:41 - 07:00 is included. Does this mean we should only care about the date portion of balanceDate? and that balanceDate of 2013-08-06 12:53:21 - 07:00 includes all transactions posted on 2013-08-06?
The LastTransactionsDate is the date of the last captured transaction in our system. The balance of the account is what we captured from the FI's website so we perform no calculation of the transactions to come up with that number. If there are pending transactions and the FI provides their balance in that fashion we will provide that value.
The BalanceDate field refers to when our system captured the balance of the account from the website. So that balance would include all the transactions posted on the website at that time and if the account is including the pending transactions you would need to include those as well to match the balance appropriately.
I am testing MIGS Virtual Payment Client on a test account. When I select payment, I am directed to the Payment Server page where I can choose between Visa and MasterCard. I have been given the following test data in the MIGS manual:
I use 123 as CSC value. However, the transaction always fail with
vpc_VerStatus=E
vpc_TxnResponseCode=2
vpc_Message=Declined //for Visa
vpc_Message=The+card+holder+was+not+authorised.+This+is+used+in+3-D+Secure+Authentication. //for MasterCard
By the way, if I select MasterCard, I am prompted "Please enter your OSID or the last 5 digits of your NAB ID" and a Credit Limit. I use OSID with value 123456 and Credit Limit 10000 respectively. (These are values I entered by myself as I was not given information what to input there).
I had a look at this Commonwealth bank and MIGS Virtual Payment Client error code but it does not solve my problem.
Any help why the transaction is being declined?
Okay, there's a handful of things here you need to understand/check out.
1. Ensure the transaction value ends in $xyz.00 or it will always decline
MIGS behaves differently in TEST and PROD. In TEST, MIGS uses the "cents" portion of your test transactions to determine what response code to return, NOT whether you have correctly provided the necessary data for the transaction. These cents values are as follows:
$ XXX.00 returns "0 Transaction approved"
$ XXX.10 returns "1 Transaction could not be processed"
$ XXX.05 returns "2 Transaction declined - contact issuing bank"
$ XXX.68 returns "3 No reply from Processing Host"
$ XXX.33 returns "4 Card has expired"
$ XXX.51 returns "5 Insufficient credit"
2. Disable 3-D Secure
It looks like you're also getting caught by 3DSECURE, also known as "Verified by Visa" and "Mastercard SecureCode". Call your acquirer/bank and ask them to disable this in TEST and Prod. Why? Invariably when this goes live, your customers will see a screen they are not expecting that asks for more information and then either pick up the phone and ask you to "fix it" or (even worse) leave your store thinking it's fraud.
Because 3-D secure has such low takeup, even most bank support staff don't know about it. Just today I had one of my clients call me about this "issue". One of their customers had called their card issuer to enquire as to what this "Verified by Visa" screen was. The bank (a major Australian bank) helpfully told them it was probably fraud and to not buy anything from that site.
3-D secure has such low penetration in Australia I'd suggest the only outcome of having it enabled is to reduce sales. Don't use it.