We have implemented a payment provider for a customer which has to be redirected to their payment site to enter the credit card data.
They're new therefore they do not have an "inline way" or API yet.
The problem is, when the user clicks "cancel" on their payment site and gets redirected back to the basket, the basket is empty because an Invoice was created.
What we do is, that when the user clicks "Pay" on our site, we process the payment provider and there we create a new PaymentResult(Attempt<IPayment>.Succeed(payment), invoice, true); with an amount of zero, because we have to redirect the user first to the payment site. After the payment returns the user back to our site we create a second PaymentResult with the amount.
But as I said, when the user clicks cancel the basket is empty because an Invoice was created with the amount of zero.
Is there a way to Succeed() the payment but without creating the Invoice? Something like Attempt<IPayment>.ExternalPayment().
@Calvin - at the moment there is no way to Succeed() a payment without creating an invoice. This is actually by design as to prevent someone being billed and risking not having a record of the what was paid for in the case the invoice creation failed for some reason.
The intended method would be to AuthorizePayment first (which will save the invoice record and empty the basket).
Then redirect to the payment provider passing the invoiceKey and the paymentKey from the PaymentResult returned from the AuthorizePayment to the external payment provider (like in the return URL construct) or in the CustomerContext like:
Then on the return, you would use CapturePayment on the same invoice using the Payment that was previously authorized.
If the user had clicked cancel, then the idea is that invoice can still be "paid" by using the CapturePayment extension off the invoice itself.
So you would retrieve the saved invoice:
var invoiceKey = new Guid(CustomerContext.GetValue("invoiceKey"));
var paymentKey = new Guid(CustomerContext.GetValue("paymentKey"));
var invoice = MerchelloContext.Current.Services.InvoiceService.GetByKey(invoiceKey);
var payment = Merchello.Current.Services.PaymentService.GetByKey(paymentKey);
var capturePaymentResult = invoice.CapturePayment(payment, payment.PaymentMethodKey, invoice.Total);
Also, if the Customer is a known customer (has logged in) you can have an order history page which lists every order the customer has made and allow them to pay for any unpaid invoices from that page as a link to some form in the event they come back and pay later. If you do this you may consider having a the unpaid invoices "expire" at some point to prevent someone from ordering something, not paying and then going back six months later to buy stuff that was on sale or lower priced than what is currently listed on the site.
@Rusty - thank you for you answer. I see the reason why it creates an Invoice.
We have to find a way how to implement that. It's not that easy as I thought. Just one problem: The user could go to the payment site, then add a new item to the basket or edit the quantity (the payment site doesn't know that because it's not inline) then pay it on the payment site and you probably have something for free.
So you have to have something "in between" like the Invoice with the Items which gets bought with the provider.
Maybe we could just re-add the Items from the Invoice to the Basket and delete the Invoice when the user cancels the payment but I don't know if there are any side effects...
Non Inline Payment Provider
Hi there
We have implemented a payment provider for a customer which has to be redirected to their payment site to enter the credit card data. They're new therefore they do not have an "inline way" or API yet.
The problem is, when the user clicks "cancel" on their payment site and gets redirected back to the basket, the basket is empty because an Invoice was created.
What we do is, that when the user clicks "Pay" on our site, we process the payment provider and there we create a
new PaymentResult(Attempt<IPayment>.Succeed(payment), invoice, true);with an amount of zero, because we have to redirect the user first to the payment site. After the payment returns the user back to our site we create a second PaymentResult with the amount.But as I said, when the user clicks cancel the basket is empty because an Invoice was created with the amount of zero.
Is there a way to Succeed() the payment but without creating the Invoice? Something like
Attempt<IPayment>.ExternalPayment().Thank you Calvin
@Calvin - at the moment there is no way to Succeed() a payment without creating an invoice. This is actually by design as to prevent someone being billed and risking not having a record of the what was paid for in the case the invoice creation failed for some reason.
The intended method would be to AuthorizePayment first (which will save the invoice record and empty the basket).
Then redirect to the payment provider passing the invoiceKey and the paymentKey from the PaymentResult returned from the AuthorizePayment to the external payment provider (like in the return URL construct) or in the CustomerContext like:
Then on the return, you would use CapturePayment on the same invoice using the Payment that was previously authorized.
If the user had clicked cancel, then the idea is that invoice can still be "paid" by using the CapturePayment extension off the invoice itself.
So you would retrieve the saved invoice:
Also, if the Customer is a known customer (has logged in) you can have an order history page which lists every order the customer has made and allow them to pay for any unpaid invoices from that page as a link to some form in the event they come back and pay later. If you do this you may consider having a the unpaid invoices "expire" at some point to prevent someone from ordering something, not paying and then going back six months later to buy stuff that was on sale or lower priced than what is currently listed on the site.
@Rusty - thank you for you answer. I see the reason why it creates an Invoice.
We have to find a way how to implement that. It's not that easy as I thought. Just one problem: The user could go to the payment site, then add a new item to the basket or edit the quantity (the payment site doesn't know that because it's not inline) then pay it on the payment site and you probably have something for free.
So you have to have something "in between" like the Invoice with the Items which gets bought with the provider.
Maybe we could just re-add the Items from the Invoice to the Basket and delete the Invoice when the user cancels the payment but I don't know if there are any side effects...
is working on a reply...