function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion

Sites pages using Linvio PaymentConnect



Has anybody worked on sites pages that uses Linvio PaymentConnect without redirecting to it's SiteCheckout page.





Hi Vishnu,


We've probably spoken with you about this in person, but I wanted to respond to your post publicly as well.  There are several reasons why you would not want to bypass the checkout page(s) provided for you in PaymentConnect.


1.  The SiteCheckout page allows you to process only payments with multiple payment processors (eWay, Google, WorldPay, PayPal, AuthNet) and as new processors are added, this page will be enhanced and available as updates to the managed package by Linvio.  This saves the customer (and you as a developer) the headache of having to update and maintain the code that handles payment management.


2. In the next release, the page will also be "aware" of the login status of the end-customer,  allowing it to auto-fill contact information during checkout if the customer is logged into your authenticated Sites portal. 


3. It will also support checkout using stored or tokenized payment methods in the authenticated context (this will be an add-on feature for PaymentConnect that you will be able to configure for portal users).


4. SiteCheckout also supports custom visualforce page flow.  You can build the pages leading up to checkout (collecting customer info, building a shopping cart of items, constructing the payment data), redirect to SiteCheckout for payment, and then, you have control over the display of a custom receipt page or "next step" page of your design that picks up the payment data and carries the workflow forward.


5. And technically, the process of sending a charge request to your payment processor requires that we send the record ID of the "In Process" Payment (a reference ID) so that asynchronous callbacks from the processor can be applied to the same transaction record (vs. accidentally creating a duplicate record).  Salesforce doesn't allow applications to create a record and then make an API callout within the same Apex transaction, so this is why we first create the payment (along with it's amount, lookup values and other payload data), finish that Apex transaction, and then process the card.


Also, it's important to mention that we don't offer a published, supported interface to the wrappers in PaymentConnect so you are developing outside of recommended best practices, without documentation and without support if you try this approach. 



Ron Wild


Linvio, Inc.