We want to allow our store to accept what we call in the U.S. a 'Purchase Order'. The name conflicts with the class in uCommerce causing a google search to be pretty ineffective.
Basically, we just need the customer to be able to enter a 'PO #' on the order to indicate they have payment terms set up with us. That is all the payment information we need entered. We don't need to route out to a 3rd party payment provider.
The built in 'Account' or 'Invoice' payment providers seem close, but we need to a place to ask the user to enter the PO#, and then we need to store that number on the Order (either in the Reference ID or custom payment property).
Is there a way to pass or set our PO# directly on the payment, so that the CreatePayment() or RequestPayments() methods store this informaiton when using the 'Account' payment provider?
Is there a way to build a customer payment provider that just shows a form to ask for the PO and then stores that information and completes the transaction?
I'm sure there are examples on how to do this but as I mentioned I'm not having luck phrasing a search to find them. If someone could share a link or sample code that would be much appreciated!
You can easily create a new payment method service by implementing the interface : IPaymentProvider.
Then you need to implement the methods.
You can use custom properties on an order and / or orderline to store a PO # from the customer and the check for that in your payment method. You can create custom pipelines for your payment method services if you need to do so, or modify the existing ones to match your needs.
I would just present a form to the customer where they can enter the information, and then store it on the order properties. Do you only have the one payment method service ? If so the above should be plenty to achieve this.
There's some guides on our site that describes the individual bits:
I have created a new assembly with my new provider. It contains three classes:
POPaymentMethodService
POpaymentMethodServiceConfigurationSection
POPageBuilder
It took me a while, but i have everything correctly set up in the web.config and custom.config files, and my payment method is now available for use in the checkout flow.
But now the question is: how do i get the RenderPage() flow to look like part of my site?
Since I am just gathering a text field from the user, i have no need to leave my website and would like the page to look like any other in the checkout flow. However, since the PageBuilder writes out the page header and body the page contains none of the website layout or dynamic content (such as macros to build navigation based on the content tree).
Is there a way to write out the payment form that makes use of the templates used by the rest of the site ot build my log, navigation, footer, etc?
Also, when my custom payment form submits, how do i tie it back into the checkout pipeline so that it completes the order?
What interface did you derrive from ? If you do not need to redirect to an external payment gateway, it should be enough to only implement IPaymentMethodService.
During checkout flow you can add a order property that you can look for in RequestPayment.
When you submit the order, depending on the context and if you're using the API's setting checkout as the pipeline should be enough. Then the framework should take care of executing it for you.
I had looked at IPaymentMethodService, but it didn't have a 'RenderPage' method that would be invoked to display the payment form, which is my key concern. I couldn't figure out how to get a payment form to display for data entry with that interface.
I am deriving from ExternalPaymentMethodService currently. It may be overkill, but I was able to get the form to display (though with the issues i mentioned above).
I can step back and start over if needed, the basic requirements are these:
have a payment provider that displays additional fields for the customer to enter
store the additional fields on the order
continue through the rest of the checkout pipeline
The reason for having a RenderPage method is to be able to POST to an external service.
If there is no need for this, you can have your input field on any page in your checkout flow. So you simply display your page as normal, and add the data to the order.
Then during the checkout flow, the order is processed by your IPaymentMethodService.
Simple Payment method question - accept 'purchase order'
Using uCommerce 3 on an existing store.
We want to allow our store to accept what we call in the U.S. a 'Purchase Order'. The name conflicts with the class in uCommerce causing a google search to be pretty ineffective.
Basically, we just need the customer to be able to enter a 'PO #' on the order to indicate they have payment terms set up with us. That is all the payment information we need entered. We don't need to route out to a 3rd party payment provider.
The built in 'Account' or 'Invoice' payment providers seem close, but we need to a place to ask the user to enter the PO#, and then we need to store that number on the Order (either in the Reference ID or custom payment property).
Is there a way to pass or set our PO# directly on the payment, so that the CreatePayment() or RequestPayments() methods store this informaiton when using the 'Account' payment provider?
Is there a way to build a customer payment provider that just shows a form to ask for the PO and then stores that information and completes the transaction?
I'm sure there are examples on how to do this but as I mentioned I'm not having luck phrasing a search to find them. If someone could share a link or sample code that would be much appreciated!
-e
Hello e,
You can easily create a new payment method service by implementing the interface : IPaymentProvider.
Then you need to implement the methods.
You can use custom properties on an order and / or orderline to store a PO # from the customer and the check for that in your payment method. You can create custom pipelines for your payment method services if you need to do so, or modify the existing ones to match your needs.
I would just present a form to the customer where they can enter the information, and then store it on the order properties. Do you only have the one payment method service ? If so the above should be plenty to achieve this.
There's some guides on our site that describes the individual bits:
http://www.ucommerce.net/en/support/documentation.aspx
Hope this helps.
Thanks for the reply.
I have created a new assembly with my new provider. It contains three classes:
It took me a while, but i have everything correctly set up in the web.config and custom.config files, and my payment method is now available for use in the checkout flow.
But now the question is: how do i get the RenderPage() flow to look like part of my site?
Since I am just gathering a text field from the user, i have no need to leave my website and would like the page to look like any other in the checkout flow. However, since the PageBuilder writes out the page header and body the page contains none of the website layout or dynamic content (such as macros to build navigation based on the content tree).
Is there a way to write out the payment form that makes use of the templates used by the rest of the site ot build my log, navigation, footer, etc?
Also, when my custom payment form submits, how do i tie it back into the checkout pipeline so that it completes the order?
- e
What interface did you derrive from ? If you do not need to redirect to an external payment gateway, it should be enough to only implement IPaymentMethodService.
During checkout flow you can add a order property that you can look for in RequestPayment.
When you submit the order, depending on the context and if you're using the API's setting checkout as the pipeline should be enough. Then the framework should take care of executing it for you.
Hope this helps.
I had looked at IPaymentMethodService, but it didn't have a 'RenderPage' method that would be invoked to display the payment form, which is my key concern. I couldn't figure out how to get a payment form to display for data entry with that interface.
I am deriving from ExternalPaymentMethodService currently. It may be overkill, but I was able to get the form to display (though with the issues i mentioned above).
I can step back and start over if needed, the basic requirements are these:
am i missing something simple?
-e
Hello e,
The reason for having a RenderPage method is to be able to POST to an external service.
If there is no need for this, you can have your input field on any page in your checkout flow. So you simply display your page as normal, and add the data to the order.
Then during the checkout flow, the order is processed by your IPaymentMethodService.
Kind regards,
Jesper
is working on a reply...