UPDATE: If you've come here looking for information about integrating PayPal into Community Server or about paid subscriptions for Community Server, I and several other Community Server technical evangelists have put together a product named Four Roads Commerce. You can find information about it at the Four Roads website.
The questions from the previous post give us a few challenges. In the long run, we need to provide access to multiple payment gateways and let you configure the payment-related settings per community. We also need a way to store those settings.
Let's figure out how to support multiple communities.
How the Community Server (CS) database supports multiple communities
If you've ever added an alias for a community or created an entirely new community, you're probably familiar with the cs_System_AddNewUrl and cs_system_CreateCommunity stored procedures. The former adds an alias. The latter adds a new community.
Under the covers, there are three tables that establish a site (i.e., community), store its settings, and map a site and its aliases to those settings.
The cs_Sites table lists the sites created via the aforementioned stored procedures. Note that each alias and community has its own record in the table. The key field is named SiteID. Following is some sample data retrieved using the statement SELECT * FROM cs_Sites.
Each community also has various settings managed through the CS Control Panel. Those settings are stored in XML format within the cs_SiteSettings table. Following is some sample data. Notice that we see only one record in the table.
How does CS map a site to its settings? Via the cs_SiteMappings table. This table maps each SiteID to a specific SettingsID. In this example, SiteID 1000 is the community and all other sites are aliases. And they share the same settings. So if I enter my community through precariousbalance.net (SiteID 1001) instead of precariousbalance.com (SiteID 1000), it correctly uses the settings defined for precariousbalance.com.
If you look at other CS tables that contain community-specific information, you'll notice that they tend to have a SettingsID field. This is to handle the case where there is one community with several aliases.
So what does that tell us? When we save our payment-related settings, we need to tie it to a community via the SettingsID. We should be able to define payment settings on a per community basis, as well as define global settings to be used for those sites not having community-specific payment settings. We can do both through the use of a SettingsID.
Following is a screenshot of the table where we'll store those settings. I'm not going to explain all the fields. The point is to see that we're tying each record to a community.
In the next post, we'll put together some interfaces to describe the payment gateway and settings.
--
Sean Winstead
Tags: CommunityServer