Dear Yolto Card customers,
Today we are announcing a new reload option that can be particularly useful for our US customers - the paper billing.
You have probably noticed that we keep adding new reload options to the Reload page: http://yolto.com/Pay/Reload.aspx . Most of them involve handling fees except for one - the paper billing.
You can order a paper bill and pay it with a personal check, cashier check or postal money order if you live in the US. The bill will be sent next business day after your billing request and typically will arrive in your mailbox in 2-5 days.
By using this reload option you can altogether avoid using credit or debit cards for your gaming needs and save on handling fees that are required by other reload methods. Pay for your game in the same way as you pay for cable TV, broadband connection or any other utility. It is simple, convenient and cheap.
Please don't forget to make your check, cashier check or postal money order payable to On-line Card Technologies, Inc. Also, please include the bill code into the Memo field of your check for faster processing. Your checks should be sent to our address: 1055 W Bryn Mawr, F286, Chicago, IL, 60660 within a month after the billing request.
We would like to remind you, that we do not allow card reloads from other people's accounts, because it could constitute a money transfer from one person to another or check cashing. We are NOT a money transfer or check cashing business - the name on your check must coincide with the name you provided to us during the card registration. If you are not sure whether you had entered your name right please open the page http://yolto.com/Pay/ click the link 'Personal data' on the left, enter your PUK key to get access to your personal details and modify them.
Please DO NOT send us cash in the envelope as a payment. Several cash reload options will be available later but they will not involve mailing the cash itself to us in an envelope. Instead we are working on partnerships with the leading cash transfer services and will implement cash reloads in cooperation with them.
Regards.
P.S. Please don't hesitate to ask questions in the comments to this post or your blog if you are a member of Metaforum.
Yolto
Yolto's talking
Sunday, August 17, 2008
Saturday, July 12, 2008
Metaforum 'Play-Per-Post' program announcement
Metaforum is a blog-feed search engine. It also has a capability of organizing blog posts from multiple blogs referencing each other or any other material (f.i. a newspaper article) into Topics. This is pretty much ‘nothing new’ – there’s a Google reader and feed search, there are Technorati and Techmeme (except for the fact that Techmeme is not covering games and VW that are our domain of interest).
At some point we realized that cross-blogosphere discussions as they are presented in our Metaforum are MORE interesting to read than conventional ‘editorials’ on big sites or individual blog posts. If arranged properly they are representing some new form of content, showing the diversity of opinions on the subject and giving a better feel of the blogosphere content in general. This is particularly so for the part of the blogosphere covering gaming experiences.
We would like to stimulate this new emerging form of discourse by giving the incentive to bloggers who participate in this type of discussions by the Metaforum ‘Play-Per-Post’ program. Every blogging gamer or resident of any Virtual World can participate in it and earn money for her/his contributions to the cross-blogosphere discussions or other materials presented on our site in the form of Topics.
The Topics are started by our editor when she notices an interesting subject covered by one source (it may be a blog post or a newspaper article or any reference) and a blog post responding to the initial material. Then every participant of the Metaforum can take part in the discussion by:
1. Expressing a different opinion
2. covering another aspect of the same subject
3. showing how this subject is connected to other subjects or topics
4. ... any other meaningful response
Posts from the blogs participating in the Metaforum are appended to the Topic automatically if the blogger includes a link to the Topic into the part of the post published in the blog feed.
As usually we would ask all contributors to try to avoid foul language and personal attacks in the posts that are supposed to participate in a Topic. Also, the text of the post should really contribute to the Topic and discuss the substance of the problem or opinion of the author. Extra short or extra long posts may be excluded from Topics by our editor or concatenated.
In the nearest future we are planning to provide the most respectable bloggers with an ability to start Topics by themselves in the same way as our editor does it now.
The remuneration for participation in the Metaforum Topics is accumulated and transferred to the Yolto Card of the Metaforum participant. This value can be used for purchases on Yolto site and other sites accepting payments from their customers through the Yolto Card payment service. Probably the most interesting option for Second Life residents will be our Game currencies store, located here: http://yolto.com/Buy/Currencies.aspx . They can buy 280 L$ for every 1$ on Yolto Card in this store (better rate than on LindeX). The store is accredited with Linden Lab and listed here: http://wiki.secondlife.com/wiki/L$_Marketplace as one of the official exchange providers. Gamers playing other games can purchase Game Time Cards in our store.
Bloggers can join the Metaforum ‘Play-Per-Post’ following the instructions published on this page: http://yolto.com/People/SetUp/ . As a matter of fact it’s a pretty much standard procedure of adding the blog feed and ‘claiming’ the blog. The second part is a bit more complex because it involves joining the Yolto Card game payments service by downloading and installing the software ‘card’ application. It is described here: http://yolto.com/Pay/ , there are several videos in the section showing how to do it.
At some point we realized that cross-blogosphere discussions as they are presented in our Metaforum are MORE interesting to read than conventional ‘editorials’ on big sites or individual blog posts. If arranged properly they are representing some new form of content, showing the diversity of opinions on the subject and giving a better feel of the blogosphere content in general. This is particularly so for the part of the blogosphere covering gaming experiences.
We would like to stimulate this new emerging form of discourse by giving the incentive to bloggers who participate in this type of discussions by the Metaforum ‘Play-Per-Post’ program. Every blogging gamer or resident of any Virtual World can participate in it and earn money for her/his contributions to the cross-blogosphere discussions or other materials presented on our site in the form of Topics.
The Topics are started by our editor when she notices an interesting subject covered by one source (it may be a blog post or a newspaper article or any reference) and a blog post responding to the initial material. Then every participant of the Metaforum can take part in the discussion by:
1. Expressing a different opinion
2. covering another aspect of the same subject
3. showing how this subject is connected to other subjects or topics
4. ... any other meaningful response
Posts from the blogs participating in the Metaforum are appended to the Topic automatically if the blogger includes a link to the Topic into the part of the post published in the blog feed.
As usually we would ask all contributors to try to avoid foul language and personal attacks in the posts that are supposed to participate in a Topic. Also, the text of the post should really contribute to the Topic and discuss the substance of the problem or opinion of the author. Extra short or extra long posts may be excluded from Topics by our editor or concatenated.
In the nearest future we are planning to provide the most respectable bloggers with an ability to start Topics by themselves in the same way as our editor does it now.
The remuneration for participation in the Metaforum Topics is accumulated and transferred to the Yolto Card of the Metaforum participant. This value can be used for purchases on Yolto site and other sites accepting payments from their customers through the Yolto Card payment service. Probably the most interesting option for Second Life residents will be our Game currencies store, located here: http://yolto.com/Buy/Currencies.aspx . They can buy 280 L$ for every 1$ on Yolto Card in this store (better rate than on LindeX). The store is accredited with Linden Lab and listed here: http://wiki.secondlife.com/wiki/L$_Marketplace as one of the official exchange providers. Gamers playing other games can purchase Game Time Cards in our store.
Bloggers can join the Metaforum ‘Play-Per-Post’ following the instructions published on this page: http://yolto.com/People/SetUp/ . As a matter of fact it’s a pretty much standard procedure of adding the blog feed and ‘claiming’ the blog. The second part is a bit more complex because it involves joining the Yolto Card game payments service by downloading and installing the software ‘card’ application. It is described here: http://yolto.com/Pay/ , there are several videos in the section showing how to do it.
Monday, June 30, 2008
Wednesday, April 2, 2008
Metaforum gets "go!"
Today we would like to announce our Metaforum service (or, maybe, it is a ‘utility’… or ‘discussion tool’… I think the term is not so important).
As some of you have probably noticed (Vint did it first :)) we had built a specialized search engine and feed reader for the readers of virtual worlds blogs, gaming blogs, and blogs about the virtual worlds/multiplayer games industry and embedded it into our site (http://yolto.com/) . In the same way as any other search engine ours crawls the web, finds relevant sources of news and information and archives them in our index for the reader’s convenience. The slight difference is: our robots connect to the publicly available feeds and start reading the feed updates (once in an hour or so) as soon as they discover a blog ‘talking’ about virtual worlds, multiplayer games or about the companies providing ‘virtual’ services. As a result of this crawling and reorganization of information three searcheable news-wires/archives of feeds are assembled, namely: “Residents say” - this one is mostly about Second Life because it is the leading virtual world but there are also some Sims, Webkinzer, There and HiPiHi feeds in it as well, “Real Life” – news about game industry and game providers/developers and “Gamers say”- this index mostly consists of WoW, Lineage, EVE-online and other multiplayer games blog-feeds archives. These searcheable news-wires/archives are available here (in the same order): http://yolto.com/FeedTopics.aspx?c=5 , http://yolto.com/FeedTopics.aspx?c=6 , http://yolto.com/FeedTopics.aspx?c=2
There are three reasons why our robots are discovering, collecting and archiving these feeds.
Readers want to discover new feeds of the blogs, ‘talking’ about virtual worlds and multiplayer games. Our robots are helping them by searching the web and doing just that – discovering new and interesting feeds. In fact these three news-wires are just the ‘self-configuring’ feed-readers (same as Google® Reader or any other). They are different because they ‘do it all by themselves’, automagically.
News-wires are not just searcheable, they present the search results in a chronological order, which is particularly useful for news, cross-blogosphere discussions and for the general understanding of the ‘course of human events’. :)
It’s not a secret that blogs appear and sometimes disappear in an instance, because the blog owner has gotten tired of it, disappointed by something… or has no time to write. Then the wonderful stories about people’s experiences in the virtual worlds, parts of their magnificent lives are just GONE… GONE FOREVER. We think that stories have to be preserved and made available to any reader at any time - tomorrow, in a year from now, maybe even forever. History is just a collection of those stories. History is being written today, that is our motto and we would like to keep this history for the future readers. We view these indexes as no less than ‘the history of people’s lives’ and consider it to be precious.
The most interesting part of the blogosphere and blogging are cross-blogosphere discussions. Readers love them. Why? Because they are free from the censorship of ‘official forums, they are open – everybody can participate, nobody can ‘ban’ anybody, and, most importantly, bloggers are just the different kind of people. We respect you, dear bloggers, for the way you express yourself in words when you are writing your diaries, for the atmosphere of overall friendliness in your talks, for the generous ways you invent to welcome new bloggers, for the helping hand you are offering to each other and to the readers. There’s no other place as the blogosphere where people are having such a polite (mmm… maybe not always J ) discussions even when they are really heated.
However, there is a problem for the reader of the discussions: it just takes A LOT of time to trace them, to understand the chronological order of the posts, to find other sources that are mentioned but not referenced directly. It’s not easy to find the discussion and start tracing it when it has just emerged. And, as I said earlier, some blogs can disappear over time too… This is a situation when a robot can help a human. J
That’s why we’ve built this highly automated thing – the Metaforum. Why this name? In fact the blogosphere as a whole is a forum – the best way that has been invented so far to freely and publicly discuss any subject. It may need some more tools though to unravel (or maybe ‘unleash’? ;) ) the power of the freedom of speech. You probably know that there are many web-sites and companies that have tried to organize cross-blog discussions into ‘memes’, ‘diggs’, ‘ranks’etc. They are all based on the presumption of one person’s or a group of persons (and their opinion) ‘authority’ over other people and their opinions and that is why in our view they are not good enough for the domain of the ‘virtual lives of the people’. Here’s what we’ve built and are offering to you as a tool:
Metaforum consists of three parts
There are three pre-configured feed-readers and three groups of topics, you may call them ‘Sections’: “Residents say’, ‘Real Life’ and ‘Gamers say’. You can participate in ANY topic once your blog feed has been included.
Metaforum is open for everybody
Every blogger can add his blog feed to the Metaforum. You don’t need to create an account, just add your blog URL and feed URL through the form at the end of any Topic Digest.
Metaforum robots will add your posts to the Topic digests automagically (as soon as they read your feed) if...
a.) you include the link to the particular Topic Digest (available at the bottom of the page) into the part of your post available through the feed;
b.) your feed has been included into our collection. In order to check it – open the news-wire reader/search page (f.i. http://yolto.com/FeedPosts.aspx?c=5 ) , enter the name of your blog in the search box and click the search button.
You can leave Metaforum at any time
Just post on you blog a post with the title: I’m leaving Metaforum. That’s it. You don’t need to e-mail us, you don’t need to explain why (we would like to hear your opinion of course, but it’s up to you whether you want to explain your decision or not) no buttons, no farewell screen... If you prefer e-mails drop us a line to mh@yolto.com. Robots will not show what you are writing on your blog to anybody. They will keep reading the feed, analyzing the links, but only the direct links to the home page or your blog and permalink to your posts will be displayed on the feed-reader and topics pages.
You can follow Metaforum topics updates on Twitter
Follow the Metaforum there and you will get updates about newly created Topics and sometimes updates about important additions to the topics.
Just a couple of words about how to read Metaforum effectively
The first page has three blocks with the latest topics in all three sections. If you use the search box on this page you will be searching in all topics of all sections. You may return to this page from other pages by clicking ‘All Topics’ in the menu on the left.
Links on the left are the multipage topic lists (sercheable too) of a particular section.
The search term DOES NOT RESET when you are browsing through pages/sections, so, if there is “Second Life” there, you will only see the topics and posts with “Second Life” term in them while you are browsing, World of Warcraft blogs will not bother you. :) In order to reset the search term delete it and press the ‘Topics Search’ or ‘News search’ button.
Feed readers (and individual post searches) are behind the small font links under the section names and at the end of each section.
Posts, participating in topics have a link to this topic (inside the frame lower left corner)
Once again, if you want to participate in a Topic – grab the link at the bottom of Topic Digest page by copy-paste and include it into your responding post.
One important question a blogger had asked me once and it probably needs to be answered in this announcement – why is it on your commerce site? For two reasons: we built this application for the customers of our digital ID service, then realized that it can be made completely open and available to every blogger who would like to participate, even without any registration. We will add an option to display verified in-world/in-game identities of Metaforum participants soon, but it will be just that – an option. Secondly, we built this software mostly for the purposes of open game-commerce, Metaforum is just a ‘byproduct’ or, better to say, just one of the many possible applications of this principle and software platform. Also, we just wanted to keep all what we are doing together. So, if you don’t need other upcoming options of our platform – just don’t pay attention to the rest, please. :) One thing I can promise you: THERE WILL BE NO ADVERTISING ON THE METAFORUM PAGES! EVER! :)
Please don’t hesitate to contact me at any time, here or by e-mail p (at) yolto.com with any questions or suggestions. We would like to keep improving Metaforum so that it would be useful for bloggers and YOU, our dear fellow bloggers, would feel comfortable with it… of course if you consider it to be useful at all. J
Also, please contact Mayday Houston mh (at) yolto.com with any technical questions or requests to make corrections or… whatever editing if it will be necessary.
Regards.
As some of you have probably noticed (Vint did it first :)) we had built a specialized search engine and feed reader for the readers of virtual worlds blogs, gaming blogs, and blogs about the virtual worlds/multiplayer games industry and embedded it into our site (http://yolto.com/) . In the same way as any other search engine ours crawls the web, finds relevant sources of news and information and archives them in our index for the reader’s convenience. The slight difference is: our robots connect to the publicly available feeds and start reading the feed updates (once in an hour or so) as soon as they discover a blog ‘talking’ about virtual worlds, multiplayer games or about the companies providing ‘virtual’ services. As a result of this crawling and reorganization of information three searcheable news-wires/archives of feeds are assembled, namely: “Residents say” - this one is mostly about Second Life because it is the leading virtual world but there are also some Sims, Webkinzer, There and HiPiHi feeds in it as well, “Real Life” – news about game industry and game providers/developers and “Gamers say”- this index mostly consists of WoW, Lineage, EVE-online and other multiplayer games blog-feeds archives. These searcheable news-wires/archives are available here (in the same order): http://yolto.com/FeedTopics.aspx?c=5 , http://yolto.com/FeedTopics.aspx?c=6 , http://yolto.com/FeedTopics.aspx?c=2
There are three reasons why our robots are discovering, collecting and archiving these feeds.
Readers want to discover new feeds of the blogs, ‘talking’ about virtual worlds and multiplayer games. Our robots are helping them by searching the web and doing just that – discovering new and interesting feeds. In fact these three news-wires are just the ‘self-configuring’ feed-readers (same as Google® Reader or any other). They are different because they ‘do it all by themselves’, automagically.
News-wires are not just searcheable, they present the search results in a chronological order, which is particularly useful for news, cross-blogosphere discussions and for the general understanding of the ‘course of human events’. :)
It’s not a secret that blogs appear and sometimes disappear in an instance, because the blog owner has gotten tired of it, disappointed by something… or has no time to write. Then the wonderful stories about people’s experiences in the virtual worlds, parts of their magnificent lives are just GONE… GONE FOREVER. We think that stories have to be preserved and made available to any reader at any time - tomorrow, in a year from now, maybe even forever. History is just a collection of those stories. History is being written today, that is our motto and we would like to keep this history for the future readers. We view these indexes as no less than ‘the history of people’s lives’ and consider it to be precious.
The most interesting part of the blogosphere and blogging are cross-blogosphere discussions. Readers love them. Why? Because they are free from the censorship of ‘official forums, they are open – everybody can participate, nobody can ‘ban’ anybody, and, most importantly, bloggers are just the different kind of people. We respect you, dear bloggers, for the way you express yourself in words when you are writing your diaries, for the atmosphere of overall friendliness in your talks, for the generous ways you invent to welcome new bloggers, for the helping hand you are offering to each other and to the readers. There’s no other place as the blogosphere where people are having such a polite (mmm… maybe not always J ) discussions even when they are really heated.
However, there is a problem for the reader of the discussions: it just takes A LOT of time to trace them, to understand the chronological order of the posts, to find other sources that are mentioned but not referenced directly. It’s not easy to find the discussion and start tracing it when it has just emerged. And, as I said earlier, some blogs can disappear over time too… This is a situation when a robot can help a human. J
That’s why we’ve built this highly automated thing – the Metaforum. Why this name? In fact the blogosphere as a whole is a forum – the best way that has been invented so far to freely and publicly discuss any subject. It may need some more tools though to unravel (or maybe ‘unleash’? ;) ) the power of the freedom of speech. You probably know that there are many web-sites and companies that have tried to organize cross-blog discussions into ‘memes’, ‘diggs’, ‘ranks’etc. They are all based on the presumption of one person’s or a group of persons (and their opinion) ‘authority’ over other people and their opinions and that is why in our view they are not good enough for the domain of the ‘virtual lives of the people’. Here’s what we’ve built and are offering to you as a tool:
Metaforum consists of three parts
There are three pre-configured feed-readers and three groups of topics, you may call them ‘Sections’: “Residents say’, ‘Real Life’ and ‘Gamers say’. You can participate in ANY topic once your blog feed has been included.
Metaforum is open for everybody
Every blogger can add his blog feed to the Metaforum. You don’t need to create an account, just add your blog URL and feed URL through the form at the end of any Topic Digest.
Metaforum robots will add your posts to the Topic digests automagically (as soon as they read your feed) if...
a.) you include the link to the particular Topic Digest (available at the bottom of the page) into the part of your post available through the feed;
b.) your feed has been included into our collection. In order to check it – open the news-wire reader/search page (f.i. http://yolto.com/FeedPosts.aspx?c=5 ) , enter the name of your blog in the search box and click the search button.
You can leave Metaforum at any time
Just post on you blog a post with the title: I’m leaving Metaforum. That’s it. You don’t need to e-mail us, you don’t need to explain why (we would like to hear your opinion of course, but it’s up to you whether you want to explain your decision or not) no buttons, no farewell screen... If you prefer e-mails drop us a line to mh@yolto.com. Robots will not show what you are writing on your blog to anybody. They will keep reading the feed, analyzing the links, but only the direct links to the home page or your blog and permalink to your posts will be displayed on the feed-reader and topics pages.
You can follow Metaforum topics updates on Twitter
Follow the Metaforum there and you will get updates about newly created Topics and sometimes updates about important additions to the topics.
Just a couple of words about how to read Metaforum effectively
The first page has three blocks with the latest topics in all three sections. If you use the search box on this page you will be searching in all topics of all sections. You may return to this page from other pages by clicking ‘All Topics’ in the menu on the left.
Links on the left are the multipage topic lists (sercheable too) of a particular section.
The search term DOES NOT RESET when you are browsing through pages/sections, so, if there is “Second Life” there, you will only see the topics and posts with “Second Life” term in them while you are browsing, World of Warcraft blogs will not bother you. :) In order to reset the search term delete it and press the ‘Topics Search’ or ‘News search’ button.
Feed readers (and individual post searches) are behind the small font links under the section names and at the end of each section.
Posts, participating in topics have a link to this topic (inside the frame lower left corner)
Once again, if you want to participate in a Topic – grab the link at the bottom of Topic Digest page by copy-paste and include it into your responding post.
One important question a blogger had asked me once and it probably needs to be answered in this announcement – why is it on your commerce site? For two reasons: we built this application for the customers of our digital ID service, then realized that it can be made completely open and available to every blogger who would like to participate, even without any registration. We will add an option to display verified in-world/in-game identities of Metaforum participants soon, but it will be just that – an option. Secondly, we built this software mostly for the purposes of open game-commerce, Metaforum is just a ‘byproduct’ or, better to say, just one of the many possible applications of this principle and software platform. Also, we just wanted to keep all what we are doing together. So, if you don’t need other upcoming options of our platform – just don’t pay attention to the rest, please. :) One thing I can promise you: THERE WILL BE NO ADVERTISING ON THE METAFORUM PAGES! EVER! :)
Please don’t hesitate to contact me at any time, here or by e-mail p (at) yolto.com with any questions or suggestions. We would like to keep improving Metaforum so that it would be useful for bloggers and YOU, our dear fellow bloggers, would feel comfortable with it… of course if you consider it to be useful at all. J
Also, please contact Mayday Houston mh (at) yolto.com with any technical questions or requests to make corrections or… whatever editing if it will be necessary.
Regards.
Saturday, February 23, 2008
Yolto card Basic API
ON-LINE CARD (sm) Basic API
(Interfaces Description)
- The Set-Up and parameters of a shop
- The reconfiguration of a shop
- Initiation of a payment
- User redirection in case of a successful payment (SuccessURL)
- The Digital Signature (digital “ticket”).
- User redirection in case of a cancelled payment (CancelURL)
- The authentication Set-up and parameters
- The initiation of an Authentication sequence
- User redirection in case of a successful authentication (SuccessURL)
- The Digital Signature (digital “ticket”).
- User redirection if the authentication has been cancelled (CancelURL)
- The examples of digital signature verification embodiments.
Overview
The Basic set of ON-LINE CARD (sm) API’s enables a Consumer (one of the Merchants the Issuer is servicing) to accept web-payments from the prepaid On-line card balances and authenticate Buyers for an access to premium web-resources (service functions, data files, media files, etc.) afterwards.
A Buyer chooses a desirable premium service or merchandise and is redirected to the Service for payment authorization (https://auth.On-lineCard.com/Pay.aspx). After the authorization process ends, depending on its result the Buyer is redirected to SuccessURL if payment has been committed or to CancelURL if not. The parameters of committed transaction are passed to the Merchant Shop by POST method along with a digital signature (“ticket”, certifying that the values of parameters are genuine if it verifies) upon Buyer’s return from the Service.
In a same manner an access session is initiated for a User, trying to access premium functionality of Merchant’s web-site and he (user) is redirected to Authentication Service (https://auth.On-lineCard.com/Authenticate.aspx). After the authentication, depending on its result, the User is redirected to SuccessURL (in case he has produced a card) or to CancelURL if he declined to produce a card. In the same way as in payment business-process the results are passed by POST method to Merchant Shop along with a digital signature (“ticket” certifying that the Service has identified the User as the card holder) when the User is returning from the Service. The response contains information about User Service ID (Account #) collated with parameters of access session. In this way the Shop can identify whether the access attempt has been paid for by searching for this User ID/Account # in the history of payments and grant access to premium resource or deny it.
System User ID (“Account #”) does not change when the user spends all the value on initial card and starts using next cards of the same Issuer when prompted by ON-LINE CARD (sm) Service in main business-processes of payment. This feature provides continuous relationships with Buyers and safety of their profiles (preferences, user properties, etc.) inside the premium service of Merchant during a reasonably long periods of time, at the same time providing periodical changes of access data (scratch Card Data ) and greater overall level of protection from password guessing.
Basic set of API was designed for applications using simplified processing of multiple low and medium value payments and simple User authentication on a web-site with the same card, that has been used for payment.
There is no need in establishing outgoing SSL connections between the server of Consumer (Issuer/Merchant) and ON-LINE CARD (sm) servers for integration; no software components or plug-ins have to be launched or configured on Consumer servers. Consumer can use very cheap hosting plans with most basic scripting capabilities.
Consumer can use other web-services if there is a necessity in enhanced (complete) set of Service capabilities, such as: outgoing transfers of value to client accounts, processing of customer activities logs, or industrial level of encryption based on asymmetric algorithms inside a channel between the Consumer and the Service (regulated financial businesses). Web-service interfaces (built according to WS-Security specifications) are described in «ON-LINE CARD (sm) Advanced API» document.
Shop Set-Up and parameters
Payment Interface is activated by checkbox on the page of “Basic API Set-Up” wizard. You need to open a “Payment Interface” page in “Set-Up” of the Shop you are configuring. The parameters are:
Account
- Merchant account number that will be accepting payments from Buyers (drop-down list of existing accounts).
Check-Out page URL
- optionally - URL of the page from which the Buyers will be redirected to the Service;
Success URL
- URL for redirection in case of successful payment authorization;
Cancel URL
- URL for redirection if the payment authorization has been cancelled by Buyer;
Payments Password
- password (key) to payment interface.
The following data is displayed below:
MerchantNamespaceId
- identifier assigned by ON-LINE CARD (sm) Service to this type of activity (incoming payment transactions) in this particular Shop of this particular Merchant;
Simple sample HTML code for your page
- most simple way to request payment using interface identifier.
Shop reconfiguration
All parameters except the Merchant Account# can be changed during the Shop life cycle. You can accept payments to another account only by creating a new Shop and configuring it properly.
Initiation of payment
A Shop generates and stores parameters of payment request (number and sum), then initiates (requests) a payment from Buyer by redirecting him with the help of HTML form with the following parameters.
URL:
https://auth.on-linecard.com/Pay.aspx
Method:
POST action="https://auth.on-linecard.com/Pay.aspx”
Parameters:
MerchantNamespaceId
- identifier assigned by ON-LINE CARD (sm) Service to this type of activity (incoming payment transactions) in this particular Shop of this particular Merchant (see beyond);
Amount
- requested amount of payment;
DescriptionSystem
- additional data, related to payment, that will be accessible to Merchant (optionally, if required by Merchant business-process);
DescriptionUser
- merchandise description, accessible to Buyer;
MerchantTransferId
- orderly number of payment request in the Shop (must be unique for the Shop).
Note: if there is no such number in payment request the resulting transaction is not associated with any number. We strongly recommend not to invoke payment interface in this way, because it may result in “double charges”.
As a result of this request the Buyer is redirected to ON-LINE CARD (sm) web-site, the payment is charged from his pre-paid card or is authorized by him with a PIN (in case of software card) and the payment amount is credited to the Merchant Account set-up to be used with this MerchantNamespaceId (see beyond) on configuration pages.
Simple example of HTML-page with payment button:
<html>
<form method="post" action="https://auth.on-linecard.com/Pay.aspx">
<input type="hidden" name="MerchantNamespaceId" value="0003-BC792C60-2E12-4D0D-9FBF-B2F60736603A">
<input type="hidden" name="Amount" value="1.5">
<input type="hidden" name="DescriptionUser" value='Test payment'>
<input type="hidden" name="MerchantTransferId" value="10">
<input type="submit">
</form>
</html>
User redirection in case of successful payment (SuccessURL)
After the payment has been successfully committed (and only in this case) the Buyer is redirected to the SuccessURL , set-up in Control Panel. The following parameters will be passed by POST method along with a “ticket” – digital signature formed as it is described below:
OppositeAccoun
- account from which the payment originated (source account);
Amount
- received amount of value (sum). Number format: delimiter – decimal point.
MerchantNamespaceId
- interface identifier;
MerchantTransferId
- order number (had been passed in initial transaction request);
DescriptionSystem
- optional data, related to payment (none if the initial transaction request had no optional data specified);
TransferId
- payment transaction identifier unique for ON-LINE CARD (sm) service;
PaymentTicket
- digital signature with the help of which Consumer can verify that the message was received from ON-LINE CARD (sm) unchanged.
Buyer redirection to SuccessURL with correct parameters and verifiable digital signature (see below) means, that the payment transaction has been committed. Merchant learns from this message who has committed the payment (SystemID = Account# is unique for ON-LINE CARD (sm) Service). Because of that Merchant can start providing the paid service or grant access to paid contend immediately and without any additional requests to ON-LINE CARD (sm) Service.
Digital Signature (digital “ticket”).
No parameter received by Merchant System (Shop) in the response of Service can be deemed true unless the digital signature (“ticket”) verifies as true. A String for signing is formed by concatenation of the following parameters values delimited by ":", coded into byte array UTF8 (in this case equivalent to ASCII, because the parameters can include ASCII symbols only!):
OppositeAccount
Amount
MerchantNamespaceId
MerchantTransferId
TransferId
If <A> represents a value of A parameter, the string will look like:
<OppositeAccount>:<Amount>:<MerchantNamespaceId>:<MerchantTransferId>:<TransferId>
The signature is formed according to algorithm HMAC-SHA1 (RFC2104, http://www.ietf.org/rfc/rfc2104.txt), the result is transformed into string according to algorithm MIME base64 (RFC2045, http://www.ietf.org/rfc/rfc2045.txt). The password, entered on page of payment interface set-up in Control Panel (“Payment Password”) encoded into UTF8 byte array (equivalent to ASCII if the password includes ASCII symbols only) is used as a key to algorithm.
User redirection if the payment has been cancelled (CancelURL)
If the Buyer has cancelled the payment on any stage, he is redirected to CancelURL. The fact, that the customer was redirected means that he decided not to authorize the payment transaction or, probably had not had sufficient funds and pressed ‘Cancel’ button to return back to Merchant’s site.
Authentication Set-up and parameters
Authentication Interface is activated by checkbox on the page of “Basic API Set-Up” wizard. You need to open a “Authentication Interface” page in “Set-Up” of the Shop you are configuring. The parameters are:
Log-in URL
- URL of the page from which User will be redirected to the Service for Authentication;
Success URL
- URL to redirect the User after successful authentication;
Cancel URL
- URL to redirect the User, who declined to produce a card;
Authentication Password
- password (key) to authentication interface.
The following data is displayed below:
MerchantNamespaceId
- identifier assigned by ON-LINE CARD (sm) Service to this type of activity (user authentication) in this particular Shop of this particular Merchant;
Simple sample HTML code for your page
- most simple way to request user to authenticate himself, using interface identifier.
Initiation of Authentication
A Shop has to initiate an access session with the User before authentication. Typically this is done with the help of ‘cookies’. Many programming environments (.NET, PHP) have embedded means for this and a session is created for every new User, accessing the Shop web-site. In order to authenticate a customer (make sure that the user trying to access a premium resource has already paid for it before) a Shop must create an “identifier of request for authentication” (“MerchantAuthenticateId”), redirect User to ON-LINE CARD (sm) service site and pass this identifier along in a request. This identifier has to be ‘unique’ for the whole Shop life cycle in order to avoid duplicate access to the same premium resource. Request:
URL:
https://auth.on-linecard.com/Authenticate.aspx
Method:
POST action="https://auth.on-linecard.com/Authenticate.aspx”
Parameters:
Simple sample HTML code for your page
- most simple way to request user to authenticate himself, using interface identifier.
MerchantNamespaceId
- identifier assigned by ON-LINE CARD (sm) Service to this type of activity (authentication) in this particular Shop of this particular Merchant (see beyond);
MerchantAuthenticateId
- authentication request identifier in the Shop (must be unique for the Shop ) – up to 200 symbols;
Most basic example of HTML code with a button for ‘Card Log-in’:
<html>
<form method="post" action="https://auth.on-linecard.com/Authenticate.aspx">
<input type="hidden" name="MerchantNamespaceId" value="0003-cf923b0c-d505-4d3a-965a-3c138c538d9c ">
<input type="hidden" name="MerchantAuthenticateId" value="SomeRandomValue">
<input type="submit">
</form>
</html>
User redirection in case of successful authentication (SuccessURL)
If the User has been successfully authenticated (and only in this case) he is redirected to the SuccessURL , set-up in Control Panel. The following parameters will be passed by POST method along with a “ticket” – digital signature formed as it is described below:
Account
- User system identifier (Account #). Merchant system can verify whether the service or resource has been paid for from this account, etc.;
MerchantNamespaceId
- authentication interface identifier;
MerchantAuthenticateId
- session identifier (passed to the Service in initial request);
AuthenticateTicket
- digital signature, confirming that the message is genuine and originates from the Service.
User redirection to SuccessURL with correct parameters and verifiable digital signature (see below) means, that he has been verified as a card holder and owner of system identifier (Account #). This indirectly identifies the User and Merchant can start providing the paid service or grant access to paid contend immediately and without any additional requests to ON-LINE CARD (sm) Service if his records show that they were paid for from this account.
Digital Signature (digital “ticket”).
No parameter received by Merchant System (Shop) in the response of Service can be deemed true unless the digital signature (“ticket”) verifies as true. A String for signing is formed by concatenation of the following parameters values delimited by ":", coded into byte array UTF8 (in this case equivalent to ASCII, because the parameters can include ASCII symbols only!):
Account
MerchantNamespaceId
MerchantAuthenticateId
If <A> represents a value of A parameter, the string will look like:
<Account>:<MerchantNamespaceId>:<MerchantAuthenticateId>
The signature is formed according to algorithm HMAC-SHA1 (RFC2104, http://www.ietf.org/rfc/rfc2104.txt), the result is transformed into string according to algorithm MIME base64 (RFC2045, http://www.ietf.org/rfc/rfc2045.txt). The password, entered on page of authentication interface set-up in Control Panel (“Authentication Password”) encoded into UTF8 byte array (equivalent to ASCII if the password includes ASCII symbols only) is used as a key to algorithm.
User redirection if the authentication has been cancelled (CancelURL)
If the Buyer has cancelled the authentication on any stage, he is redirected to CancelURL. The fact, that the customer was redirected means that he decided not to produce any card and pressed ‘Cancel’ button to return back to Merchant’s site.
Examples of digital signature verification embodiments.
The HMAC-SHA1 algorithm is used to verify digital signatures upon User return to Merchant site. It is embedded into PHP, and .NET environment. There is a widely spread Perl module too. Here are the examples of digital signature validation for payment interface, the authentication ‘ticket’ is verified in the same way with different parameters, passed to Merchant system by POST method (see beyond).
ASP.NET (C#)
string paymentTicket = Request.Form["PaymentTicket"];
string oppositeAccount = Request.Form["OppositeAccount"];
string amount = Request.Form["Amount"];
string merchantNamespaceId = Request.Form["MerchantNamespaceId"];
string merchantTransferId = Request.Form["MerchantTransferId"];
string transferId = Request.Form["TransferId"];
// you could check that passed MerchantNamespaceId is an id of your
// merchant
string password = "securepass1";
string toSign = oppositeAccount + ":" +
amount + ":" +
merchantNamespaceId + ":" +
merchantTransferId + ":" +
transferId;
System.Security.Cryptography.HashAlgorithm hasher =
new System.Security.Cryptography.HMACSHA1(
System.Text.Encoding.UTF8.GetBytes(password));
byte[] aToSign = System.Text.Encoding.UTF8.GetBytes(toSign);
byte[] digest = hasher.ComputeHash(aToSign, 0, aToSign.Length);
string digestString = Convert.ToBase64String(digest);
if (digestString != paymentTicket)
{
// complain
}
else
{
// ok, valid signature
}
Perl
# as a part of SuccessURL script
# connect standard module for building HMAC-SHA1-signs
use Digest::HMAC_SHA1;
use MIME::Base64;
# define function for retrieval http-paratemters
sub Http_PostPrm;
# your registration data
my $password = "securepass1"; # merchant's password here, use only ASCII chars
# load parameters
my %q = Http_PostPrm();
# loaded parameters: $q{OppositeAccount}, $q{Amount}, $q{MerchantNamespaceId},
# $q{MerchantTransferId}, $q{TransferId}, $q{PaymentTicket}
# you could check that passed MerchantNamespaceId is an id of your
# merchant
# build data to sign
my $toSign = "$q{OppositeAccount}:$q{Amount}:$q{MerchantNamespaceId}:";
$toSign .= "$q{MerchantTransferId}:$q{TransferId}";
my $hasher = Digest::HMAC_SHA1->new($password);
$hasher->add($toSign); # or addfile
my $digest = encode_base64($hasher->digest); # 'b64digest' doesn't pad
# define the correctness state
my $isCorrect = ($digest eq $q{PaymentTicket} ? 1 : 0);
if (!$isCorrect)
{
print "Content-type: text/html\n\nbad sign\n";
die "incorrect sign passed";
}
# OK, payment proceeds
print "Content-type: text/html\n\n";
print "Thank you for using our service\n";
exit();
# just function to load http parameters, you can use your own
sub Http_PostPrm
{
my %query;
# POST params
my ($q_sz, $i, @q, @cmd);
my $l = $ENV{'CONTENT_LENGTH'};
my $qtext = "";
while ($l > 0)
{ $l -= sysread(STDIN, $qtext, $l, length($qtext)); }
@q = split("&", $qtext);
$q_sz = scalar(@q);
for($i=0; $i<$q_sz; $i++)
{
@cmd = split("=", $q[$i]);
$cmd[1] =~ s/\+/ /g;
$cmd[1] =~ s/%([0-9A-Fa-f]{2})/chr(hex($1))/eg;
$query{$cmd[0]} = $cmd[1];
}
return %query;
}
PHP
// as a part of SuccessURL script
// your registration data
$password = "securepass1"; // merchant's password here, use only ASCII chars
// HTTP parameters used: OppositeAccount, Amount, MerchantNamespaceId,
// MerchantTransferId, TransferId, PaymentTicket
// you could check that passed MerchantNamespaceId is an id of your
// merchant
// build data to sign
$toSign = "$OppositeAccount:$Amount:$MerchantNamespaceId:";
$toSign .= "$MerchantTransferId:$TransferId";
$digest = base64_encode(HmacSha1($password, $toSign));
echo "$digest";
if ($digest != $PaymentTicket)
{
echo "bad sign\n";
exit();
}
// OK, payment proceeds
echo "Thank you for using our service\n";
//Calculate HMAC-SHA1 according to RFC2104
// http://www.ietf.org/rfc/rfc2104.txt
function HmacSha1($key, $data)
{
$blocksize=64;
if (strlen($key)>$blocksize)
$key=pack('H*', sha1($key));
$key=str_pad($key,$blocksize,chr(0x00));
$ipad=str_repeat(chr(0x36),$blocksize);
$opad=str_repeat(chr(0x5c),$blocksize);
$hmac = pack('H*', sha1(
($key^$opad).pack('H*',sha1(
($key^$ipad).$data))));
return $hmac;
}
Questions? ñontact: dev@On-lineCard.com
© On-line Card Technologies, Inc.
150 N Michigan Ave. suite 2910
Chicago, IL, 60601
USA
150 N Michigan Ave. suite 2910
Chicago, IL, 60601
USA
Friday, January 25, 2008
I've just made the very first re-load!
First re-load was made succesfully! Congratulations!
Actually we've made three transactions, two of them were e-checks and are pending for this reason, one - CC transaction and it worked fine.
Once again, congratulations to everybody!
Actually we've made three transactions, two of them were e-checks and are pending for this reason, one - CC transaction and it worked fine.
Once again, congratulations to everybody!
Subscribe to:
Posts (Atom)
