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.
Related
I create a sponsored account with '0' XLM balance. To remove it using the sponsoring account, I use the accountMerge operation, but the subsequent endSponsoringFutureReserves operation fails to access the merged account - preventing the whole transaction from running. If I create a sponsored account with '0.0002' XLM balance, I can merge it when it is the transaction's source. Can the merging be done by the sponsoring account instead? TIA
You can create a regular (non-sponsored) transaction with the account_merge operation and then wrap that transaction in a FeeBumpTransaction paid by any (e.g. the sponsoring) account.
Presume a user would like to withdraw $5.00 balance on a website for PayPal balance. So they hit a withdraw endpoint which makes sure they have enough balance, calls PayPal pay api, and deducts the users on-site balance in a single serializable transaction.
What would happen if the database server drops and the transaction fails to commit after the PayPal pay request is executed successfully and the users gets their on-site balance back?
Is there a way I can encapsulate all of these calls in one atomic transaction?
I assume you are looking for two-phase commit
https://www.postgresql.org/docs/current/static/sql-prepare-transaction.html
PREPARE TRANSACTION prepares the current transaction for two-phase
commit. After this command, the transaction is no longer associated
with the current session; instead, its state is fully stored on disk,
and there is a very high probability that it can be committed
successfully, even if a database crash occurs before the commit is
requested.
Once prepared, a transaction can later be committed or rolled back
with COMMIT PREPARED or ROLLBACK PREPARED, respectively.
(empasis mine)
You shouldn't try to do this atomically. The nature of internet APIs makes this impossible.
You should probably do something resembling this pseudocode:
payment_id = random_payment_id()
try:
db:
insert into payments (payment_id, order_id, payment_amount, status, created)
values (:payment_id, :order_id, :payment_amount, 'pending', now());
commit;
remote.create_payment(payment_id, payment_amount);
except remote.error:
throw payment_error
On payment confirmation:
try:
remote.execute_payment(payment_id);
db:
update payments set status='completed' where payment_id=:payment_id;
commit;
except remote.error:
throw payment_error
And periodically you have to check a status of 'pending' payments, as you can't be sure that you'll receive all payment confirmations:
db:
select payment_id from payments
where status='pending' and created<now()-'10 minutes';
for payment_id in db.result:
if remote.payment_status(payment_id) == 'approved':
remote.execute_payment(payment_id);
db:
update payments set status='completed' where payment_id=:payment_id;
commit;
You should also periodically clean expired unconfirmed payments:
db:
select payment_id from payments
where status='pending' and created<now()-'10 days';
for payment_id in db.result:
remote.cancel_payment(payment_id);
db:
update payments set status='failed' where payment_id=:payment_id;
commit;
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
For Every PaypPal interaction we Do:
1.SetExpressCheckoutReq
2.GetExpressCheckoutDetailsReq
3.DoExpressCheckOutPaymentReq
I do create a billing agreement first and only on scheduled/subsequent orders we use this billing agreement for reference transaction.
Our Issue is:
With a new PayPal account (testpaypal#abc.com) DoExpressCheckoutPaymentReq failed for CITY = SuttonsBay, with the address validation error “10736” (Shipping Address Invalid City State Postal Code) for a user (USER A). And this was corrected in the subsequent request as Suttons bay.
But the same PayPal account(testpaypal#abc.com ) used for the second time with a different user (USER B) on the site, DoExpressCheckoutPaymentReq call succeeds for the wrong CITY = SuttonsBay and allows us to complete the order.
It is to be noted that on all scheduled order of the user, we use the DoReferenceTransactionReq, which has strict validation and this fails every time, esp. for the second scenario described above.
I would like to know why there are inconsistencies in Shipping address validation for DoExpressCheckoutPayment. It is because of this difference that our scheduled orders fails (as described in scenario 2 that allows incorrect address)
Do we any way to have strict Validation in DoExpressChecOutPayment - which solves our purpose?
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 ?