You need to sign in to do that
Don't have an account?

Using Payment Connect
Hello,
Has anybody worked on sites pages that uses Linvio PaymentConnect without redirecting to it's SitesCheckout page.
Thanks,
Vishnu
You need to sign in to do that
Don't have an account?
Hello,
Has anybody worked on sites pages that uses Linvio PaymentConnect without redirecting to it's SitesCheckout page.
Thanks,
Vishnu
There is no direct API of Linvio PaymentConnect yet to achieve this. The only one now is to fill the contact object with required details and associate it with payment object and then redirect to sitecheckout page. sitecheckout page is for One-Time payments. and for recurring payments you have to use sitesubscribeARB.
All Answers
I am working on that very subject as we speak. Not successful yet, but I should be able to provide some insight over the next few days.
There is no direct API of Linvio PaymentConnect yet to achieve this. The only one now is to fill the contact object with required details and associate it with payment object and then redirect to sitecheckout page. sitecheckout page is for One-Time payments. and for recurring payments you have to use sitesubscribeARB.
More specifically, it actually is possible (I did achieve a level of success with this mechanism), but because of platform limitations, it's burdensome. You must two a two-step screen in order to successfully do this. Here's some snippets of data (this is a PayPal version):
This is their "Level 3" integration, and a total pain in the rear. The Recurring payments feature is even more burdensome, as you have to replace Step 2 with something like this:
createNVP is just a function that puts all the parameters into a NVP string as you'd do for PayPal directly.
Note that you don't need to store CVV, CreditCardNumber, ExpDate, or any other details anywhere in your system. Once handed to PayPal, you'll receive notifications through their Payment Relay of updates to your opportunities/payments/etc. You can use the fields they've provided to trigger workflow rules (such as emails), when the record is processed successfully. Note that additional fields may be required depending on your specific use case (i.e. if there is a trial fee, trial period, etc). Note that my subscription above is infinitely recurring; you can provide additional options to limit the number of times it processes, etc.
In either event, you'll need to create a page that does something like this:
After over a month of experimentation, costly consultation with Linvio, and so on, we basically found that you might as well use SiteCheckout and save yourself the hassle.
Hi sfdcfox
I am checking this post after a long time. Thanks a lot for the research. This might come handy to me in future...
Vishnu
Thanks sfdcfox for posting this here. This is a concern for us as well.
Perhaps I can shed a little more light on the matter. There are two significant technical issues to deal with when doing visualforce/Sites customizations on top of PaymentConnect:
1. The Force.com platform does not allow you to make a DML database insert just prior to making an API callout in the same transaction. So if you wanted to store details about the customer and custom fields on the payment record and then send the credit card charge request on a single page, you'd get an error from Salesforce saying you have "uncommitted changes to the database".
At first glance, you might suggest making the call first and then saving the contact information and custom fields, but there's a catch there as well. PayPal and AuthNet send an IPN or silent post in addition to responding to your api call, and since PaymentConnect handles both, you can end up with duplicate transaction records in the system. We ensure that this doesn't happen by including the unique Payment record Id in the initial charge request and looking for it in all asynchronous posts handled by our relay scripts. So we're back to having to create the Payment record prior to requesting the charge.
We've created pre-built visualforce pages for checkout so you won't have to worry about these issues and can still deploy custom solutions to Sites, however these do require the record Id of the Payment or Recurring Payment Profile that you want to process as parameters. This is the "two step process" sfdcfox is referring to above. The developer sets up the transaction, storing contact details, creating an "In Process" Payment record and storing any custom field values you want to have in the system after the transaction has been processed succesfully. Then the record Id is passed to the SiteCheckout or SiteSubscribe page along with optional parameters for where you want to redirect on cancel or finish, and the customer reviews/updates cardholder billing information and credit card details and submits.
2. The other issue has to do with the eccentricities of managed packages. We use the $Site Template global variable in our prebuilt Sites checkout pages so that the developer can "skin" the pages with custom header, footer, css, etc and make the page an integral part of a bigger Sites implementation. However, if you insert unmanaged $Resource or component references (e.g. <c:mycustomfooter>) in your your site template page, you'll get an error when trying to view a managed page on the site.
Here's why: Salesforce has a short-cut convention within managed packages that allows developers to leave off the package prefix when referencing resources, components, objects and fields. This backfires in a site template, because the compiler thinks it is in the context of a managed package when it loads the page, and it assumes that the unmanaged resources and components in the template (which have no prefix) must be part of the package too ... and inserts the package prefix. So when displaying a PaymentConnect packaged page, "$Resource.mycssfile" becomes "$Resource.pymt_mycssfile" and can't be found. Salesforce knows about the problem - we don't know when they plan to give us a solution. Personally, I think having a standard prefix like "noprefix__" would do the trick.
It seems that even when we explain these two issues to first-time PaymentConnect integrators, we stil end up fixing code and re-explaining them ... and the problems always seem to pop up in the final minutes before a major project launch. So it causes considerable stress and additional cost for everyone - including us. We recommend leveraging the existing, pre-built checkout pages. The prebuilt pages get updated with new releases, so your customizations are "future-proofed" and it will fast-track you to a custom solution. We also provide documentation and sample code for this type of integration.
However, if you absolutely have to go down the path of making direct calls to the PaymentConnect API classes, remember that these are undocumented and we can't offer free support for all the custom code out there. You'll probably want to consider working with a Linvio partner who has done it before, or call Linvio about professional services.
Regards,
Ron Wild
President/CTO
Linvio, Inc.